Split to volumes...

It would be a nice feature if someone wrote some function which could split an installer in two or more pieces and merge them together when installing.

Something like this:
SplitInstaller chunksize [disk1Name] [disk2Name] [...]

This should generate files like setup001.bin, setup002.bin, etc.. in the $outdir directory and the user could put them on disks. The name of the disk would be shown when the installer asks for a specific disk (e.g. "Please put CD 2 in drive E:, and press OK to continue.") when the file isn't found it the directory where the installer resides.
The checksum checking should be done when a certain disk is put in the drive, because you can't ask a user to insert all disks just for the checksum, befor installing. ;-)

If anything I wrote here needs further explanation, please ask.

It seems this topic has already been hashed over, but I was wondering if anything had been done since this post was last visited...

Nope. It's planned for NSIS 2.1 at the momemt.

So, what are the chances of this kind of feature being implemented, and how much work would it take (not being a stranger to SourceForge, but having never seen the NSIS code, if it's simple enough I could add the feature myself, but I'd need a rough estimate first).

Well, it isn't a simple thing you can add in less than a day. Lets say, two weeks?

This being said, assuming no multi-volume spanning code get's written, does anyone see any big caveats to having a set of two installers, each with half of the data, the second being a silent installer (which I would assume grabs the install dir from the registry or a command line parameter launched from the first?)?

Yes, if your script will need anything from the first installer and Windows will not have it on chace, it could crash because it will try to read from a memory range that isn't there. As the header, including the script is copied into memory this might only happen if you try to extract something after the CD was switched or in the weird case that Windows flush out a code page which it will later need. The best way to avoid it will be to create 3 installers, and have the first one execute the other two. The first one will be as small as possible so Windows will have no problem caching it all. It's probably also possible to force Windows to keep it all in cache, but I don't know how yet.

The first one will be as small as possible so Windows will have no problem caching it all. It's probably also possible to force Windows to keep it all in cache, but I don't know how yet.

Why not copy the small installer into the temp dir and run it, maybe with some text file in the same dir that can be used to tell the small installer where the files are.

Originally posted by virtlink
It would be a nice feature if someone wrote some function which could split an installer in two or more pieces and merge them together when installing.

The problem with this would be that in our case, with a 1GB installation, it would take *two* gigs to install the game, since it would involve merging the installer. And, there are in fact quite a few programs that do such a thing (heck, I wrote one for floppies in DOS, 8 years ago, but when using it on CDs, it's dang friggin' annoying).

Anyway, the 2 or 3 installer thing would probably work best, I'll look at that if we can't fit on one CD. I don't see any problem with just 2 installers if launching the second one is the last thing that the first one does, although for a clean install process I guess it might be better to have one wrapper installer that knows when either of the other two got cancelled so that you don't get desktop shortcuts to things that aren't really there yet.

Part of a post originally posted by Wasteland
The problem with this would be that in our case, with a 1GB installation, it would take *two* gigs to install the game, since it would involve merging the installer. And, there are in fact quite a few programs that do such a thing (heck, I wrote one for floppies in DOS, 8 years ago, but when using it on CDs, it's dang friggin' annoying).

I really don't see why a 1 Gb installer would take 2 Gb's when split. I tought that when you split the installed files just between two files, you'd only need an installer which can switch to the second disk/CD and install the files from there.
The first n files are included with the installer in, let's say, setup.exe. The rest of the files are stored in the second file, and only read BY the installer. Thus, the installer would be a working installer without the need to merge the two (or more) files together BEFORE installing.

You'd have to write an advanced function for this in the NSIS source, since this can't be done (properly) by a plugin.

Part of a post originally posted by Wasteland
(...)I don't see any problem with just 2 installers if launching the second one is the last thing that the first one does, although for a clean install process I guess it might be better to have one wrapper installer that knows when either of the other two got cancelled so that you don't get desktop shortcuts to things that aren't really there yet.

When you'd only have two installers, you could have the following problem:
- The first installer is loaded into the memory.
- Performs it's tasks, unpacking files, etc..
- It wants to start the second installer, located on another volume (disk/CD). When inserted, the first installer can't reach it's own executable anymore, and the system *could* crash.

The 3 installer solution would be:
- Let the first installer copy itself to the harddisk (small, fast).
- Installer nr. 1 executes nr. 2, and when finished, nr. 3.
Nr 2 and nr 3 may just be silent installers. The first one provides the interface.

Atleast I think so 🙂. Maybe Kichik can clarify it better, or improve my description at some points.

Well, the solution to the possibility of the first installer crashing is that you include it on *both* discs. When you swap CDs, the file is there on the new disc. I've seen this done before (unused identical copy of an installer on a second disc), and I believe it would stop the possibility of it crashing. Should be pretty easy to do a test to see if Windows handles this gracefully, but I think it would fix the issue. Granted this installer would have to be small, and therefore you'd need 3 installers anyway (1 manager, 2 for data), but it would alleviate the need to copy the first installer to the hard drive.

I don't think that a second unused copy of the first installer will work. The copy won't be at the same byte location on your 2nd CD as it was on your 1st. Thus, the executable still can't find it's own code. And as KiCHiK said:

Part of a post originally posted by kichik
(...)As the header, including the script is copied into memory this might only happen if you try to extract something after the CD was switched or in the weird case that Windows flush out a code page which it will later need.(...)

Meaning that the -in memory loaded- executable may need it's own executable file. So it isn't unused anymore.

Maybe have an easy way:

1) Copy the installator (without any files inside it) to $TEMP.
2) Copy selected files inside CD to HD.
3) When you know that need the second one CD, put a message box saying to put the 2nd CD.
4) Copy selected files inside CD #2 to HD.
5) Continue to run other codes...

Or if you don't want to the files be too exposed...

1) Copy the installator (without any files inside it) to $TEMP
2) Execute a second installer, using a special command line code, to start to extract the files.
3) When you know that need the second CD, close the second installator and put a message box saying to put the 2nd CD.
4) Execute a third installer, using a special command line code, to start to extract the files.
5) Close the third installator and continue running the other codes...

Here I go bringing up an old thread again...

So our software definitely needs to span 2 CDs. So, the way I was planning on doing this is like so:

Wrapper installer (tiny), copies Main installer (small) to a temporary folder, and then executes Main installer.

Main installer copys files (or rather runs sub-installers) from each of the 2 CDs.

Now, here's the problem. How to delete the Main installer?

After I tried to have the Wrapper installer copy the Main to the plugins dir, but that gets deleted as soon as the wrapper exits. So, if the wrapper starts, copies, then launches Main, and then immediately exits, it won't be able to delete Main because it's in use. If the wrapper program does an ExecWait, the OS complains with a "Wrong Volume in Drive X:" message when you remove Disc 1 and insert Disc 2 (because the Wrapper requires it's .EXE image to be accessible). This *could* be solved by having Main issue a "Please insert Disc 1 again" before it exits, but I have to say having to insert Disc 1 just so the program can exit is really lame.

I tried having the Main installer attempt to delete itself as the last line, but that obviously didn't work.

Any bright ideas? Maybe a 3rd program, residing on the 2nd CD that Main calls when it's done, which passes the path to Main and has it delete it and then exit... but that just sounds hacky...

I know this probably is a silly question but have you tried this

Delete /REBOOTOK yourmainfile.exe

Vytautas 🙂

Assuming the main installer isn't that big, it shouldn't be that bad if the wrapper delete it after reboot. If it's really huge, you can copy a small wrapper to disk which will also delete the main installer.

You can also find some nifty tricks at http://www.catch22.org.uk/tuts/selfdel.asp

I guess I assumed the /REBOOTOK would mean the intaller will prompt for a reboot when it's done (I didn't actually try it). And having an install for a game require a system reboot is ridiculous. I haven't rebooted my Win2K3 system *since I first installed the OS and booted*, besides when physically adding hardware.

I ended up going the route of putting yet another wrapper-like installer on the CD (on both CDs, actually), that when the main install finishes it calls this executable on the CD which deletes the main install from the temporary folder. I guess this has a chance of failing, since if the install was cancelled because the user ejected the CD, it might not be there, so I guess I will add a Delete /REBOOTOK if the call to Exec the deleter fails. The deleter does a delete/sleep/loop until it manages to delete the main installer or times out.

If people are interested, I could probably post the majority of the City of Heroes installer, or at least the install from multiple CDs parts. I don't have enough time at the momement to actually clean it up enough to make a nice Archive posting of it though. And I'll wait until QA has banged on it a bunch to make sure it doesn't have any bugs 😉.

About problem with CD changing. I looked, how other installers solveing this problem. InnoSetup does as follows:
1. Copies small installer to temp.
2. Runs it.
3. That small installer from temp does all installation work.
And than installer can delete itself, as described in the article

http://www.catch22.org.uk/tuts/selfdel.asp.

Any news on Splitting into Volumes?

Today I was really brought down to find out that NSIS still doesn't allow to split a setup file into several volumes for several CDs.
And it's mid-2006 already... And now games are often released on 2,3 and more CDs! Where is the power of NSIS?

Maybe I'm wrong and it's just that I didn't find how to do it? Even the old versions of CreateInstall include this option so I'm even starting to think of coming back to it.🙁(

NSIS isn't automated in this area. Generally, like most things in NSIS it is up to the developer to handle things like this themselves.

Rather than automatic volume splitting it'd be logical to just have multiple NSIS installers each doing their own parts of the installation process.

I'll have to write up a Wiki page for this sometime, as it'd indeed be very useful. It won't come in a simple form mind you - there will undoubtably be a lot of overhead code.

-Stu

That sounds sad...I hoped something has changed in the 3 years that this tread is running..So the only way out so far is using another installer, until you write it?

Try this out:


-Stu

Re: Any news on Splitting into Volumes?

Originally posted by BigBooster
Today I was really brought down to find out that NSIS still doesn't allow to split a setup file into several volumes for several CDs.
And it's mid-2006 already... And now games are often released on 2,3 and more CDs! Where is the power of NSIS?

If your product takes several CDs, there's no need to encapsule the files into 1 large setup file which is compressed to boot. This is extremely ineffective speed and end-user compatibility wise. I'm sick of seeing these inept installers for games using NSIS, that copy whole 500-700mb of NSIS setup to user $TEMP (some even CRC checking itself, wow), extract it there and then do the install. What if user has some low end system or simply low HD space available on system drive for whatever reason?

You could make "external" NSIS installer.

As for the 2006 thing... I heard that there's such thing as DVD out there. I even heard it has bigger capacity than CDs! And that some game publishers already use it... 🙂

As for the 2006 thing... I heard that there's such thing as DVD out there. I even heard it has bigger capacity than CDs! And that some game publishers already use it ...

Such as Codemasters for their V8 Supercars 2 PC game, as well as GT Legends, and the limited edition of TRS2006 by Auran is also on DVD.

There is one very good solution to disk spanning here 😁.

Hey,

As far as I'm concerned (and our company do sell games like Tomb Raider legends (>2Go game) with NSIS installer) I agree on the fact that multi volume should be a native and easy to implement functionality of NSIS.
And CABSetup or multi installer (like Afrow UK exemple) aren't a solution in my case, CopyFiles + CRC check neither.
But NSIS is free...

If it's possible to do it without built-in NSIS support, then I very much doubt built-in support will be added.
I also very much doubt it'd be easy to implement.

I'll make another example script today which uses CopyFiles.
I should probably also update the existing multi-volume examples to disable CRC check - after all they aren't as likely to be corrupt on a CD.

-Stu

I am curious, what is that you need/want that CABsetup and/or Afrow UK's solution do not provide (other than I need to tidy up the progress bar in CABSetup...)?

CABSetup was built on the idea that most big installers/setups are copying large chunks of data files.

I believe it addresses this problem quite well.

Even MSI installers at their heart end up packaging the various source data files into cabinets (.CAB files) and then bundling those into the MSI database along with the event sequences (.MSI). This database spans disks pretty much the same way CABinets are spanned in CABSetup. (Have a look at the MAKEMSI or WIX projects for ideas around how they handle the MSI based installers.)

CABSetup is still pretty young, and I have a fair bit of work to go, so I am happy to take suggestions. I am interested in what feature(s) you find lacking and if you have any ideas about how else this could be handled.

Your thoughts please.

Duncan (Mr Inches)

I think generally people want NSIS to be on top of the world, when in reality there's currently only one main developer and he is now away more than ever!
In other words, if we need something done, we need to do it with what resources we currently have 🙂

I have added a CopyFiles example to the existing multi volume example.


-Stu

Originally posted by Mr Inches
I am curious, what is that you need/want that CABsetup and/or Afrow UK's solution do not provide (other than I need to tidy up the progress bar in CABSetup...)?

Well, hard to answer.
Because we use a DRM that require weird things to be done on the installer, so that while installing, others weird things are also done... Only NSIS survived this (not Inno Setup :/) Using an installer packaged in another installer complicates this.
So I'm trying CABSetup (as I don't want to pay 2500euros for an InstallShield licence!), but I need time to implement it. (and for me it's not that easy, as Inno Setup is managing disc spanning as an internal native functionality)

NSIS is on the top of the world installer, except disk spanning 🙂

I'll give you my thoughts about CABSetup as soon as I got some.

Cédric.

You should have a look at the examples that I've made as well. It really isn't complicated at all.

-Stu

Thanks for Multi-volume_Distribution, a really good demonstration of the power of NSIS!

In my view it lacks only one but extremely important thing:
cancelling of autoplay. This means that with every new disk inserted into the drive a new window opens, so the user can do something wrong in this case. Even MSDN highly recommends to eliminate this situation for multi-volume installers.

I tried to implement this feature myself, but I couldn't.
Please, show me a way of solving this problem!

MSDN recommends to insert something like this:

UINT g_uQueryCancelAutoPlay = 0;

LRESULT WndProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch (uMsg)
{
...
default:
if (!g_uQueryCancelAutoPlay)
g_uQueryCancelAutoPlay = RegisterWindowMessage(TEXT("QueryCancelAutoPlay"));

if (uMsg && uMsg == g_uQueryCancelAutoPlay)
return TRUE; // cancel auto-play

}
}

2 "ifs" - and that's all!!
But I have no idea how to insert it in NSIS 🙁

You can subclass the window with a plug-in, just like the shutdown suppression plug-in.

Thank you very much, with your sample I did it in a couple of minutes🙂
My deepest respect to NSIS and its creators!
You made a great thing!