Split to volumes...

Is it possible in NSIS to make multi volumes installation ?
I want to make installer for my Unreal Tournament and the installer I got more than 700Mb... I need to write it on CD.

Use CopyFiles or the ExtractDLL plugin.

Hm. But I want to pack my files. If I use CopyFiles than I must have them unpacked or run external archiver to extract files from second CD. It's not good.

I think there is no option in NSIS to split installation on volumes 🙁

It will be great:
mysoftinstall.exe
mysoftinstall.ns1
mysoftinstall.ns2
...
mysoftinstall.nsN

You are right, there is no possibilty to do this and it is not planned for the near future. For now you can either use them uncompressed or use one of the plug-ins in the archive that allow you to extract from archives, ZipDLL for example. You can automate the compression with !system and command line archivers (7zip provides such a tool for example).

For simple zlib compression, use can ExtractDLL, which you can find in the archive.

In the old days, when internet was new, everyone used floppydisks. The programs where spread among three or more disks. And now I wonder, why NSIS doesn't support Multi-volume installation, while the principle is already so old.

I really think that it should be on the TODO list for the near future, and not for NSIS 3.

A temporary solution: use multiple installers. The first one has the UI, the others are silent installers.

I don't understand why anyone needs multi-volume functionality, surely everything is distributed on cd or via the net now?

And an installer that is distributed on cd's might be larger thn 700 Mb. Then it needs at least two CD's.

And a small 1.8 Mb installer can be distributed on two disks.

This is my idea
[list=1][*]Compress you files in a zip format[*]use ZipDll plugin to extract all or some of the files[*]use $EXEDIR, for that you might put all your files in the same folder as your app[/list=1]

More or less as KichiK posted
👍

[edit]
Correction: Is like KichiK posted, you might ignore
this post 🙁
[/edit]

[edit]
Maybe support or have plugin for CAB format, to use with
the internal extractor that Windows have; when we use
an INF file: example, for install drivers. 🙂
[/edit]

Because a floppy disk is not a common distribution media anymore, a split function won't be added soon.

There are compression plugins available for a lot of formats, and you can also call command line utilities using nsExec.

So it isn't difficult at all to create an multi-disk installer.

From a purely "ooo look they used NSIS!" point of view I now think we need disk-spanning support in NSIS itself. I say this because a recent game, Haegemonia, used NSIS to install and if more games did this it would be great for NSIS. However, many games now are more than a single CD so I think where we've been seeing disk-spanning in terms of floppy disks we've missed the fact that games frequently span cds never mind disks!

I'm not saying whether it should be done now or in v3 or whatever, just that I can now see why it should be done at all 🙂

P.S. I know it can be achieved in other ways without built-in support but it's the kind of thing computers are good at and people shouldn't have to go to a lot of effort to work out how to do.

Sure, disk spanning can also be used for CD's.

However, integrated support will increase the overhead. And why not zip the files and extract them using ZipDLL? It's only one line of code 🙂

The only downside I can see to that is that the user has to make the decision about where the boundary of files for cd 1 and cd 2 is, which is a real pain. NSIS could work that out itself with no pain to the user.

I don't not whether ZipDLL supports multi-volume ZIP files, but an exteral compression utility will support it.

You still have a problem though, you lose the ability to work with individual files in the installer because then you'd have to pack them separately which means that your external program has to be able to understand that it has to leave some space. Sometimes you'd want to pack files seperately, e.g. a banner background image or whatever. Can external programs that understand spanning be instructed to make a file that is a certain size rather than just to span in cd size chunks? Even if they can you are again making the user work out how much space they have to work with.

Maybe the installer graphics and interface will take a few KB's, so you can let it generate 649 MB parts.

You say that adding multi-volume support makes the header bigger. But that is determined by the compiler, right? So if you would use an instruction which specifies the 'hack and slash'-size, only then the header becomes bigger. If you don't use that instruction, the header stays small. And, what do some Kb mean on a multi-volume installation that spans several CD's?

No, the NSIS VM will always become larger, otherwise everyone has to recompile NSIS to use this feature.

I'm not saying that it wouldn't be a nice feature, but it is already possible and there are lots of more important thing to do.

You should at least put it on the TODO list. Or maybe, a plugin can be written for it (ZipDLL with multi-volume support).

It's already in the Feature Request list on the SF Project Site.

TODO.txt contains all features we want to add before NSIS 2 Final will be released. This one has no high priority.

if it makes a difference, I still distribute some things on floppy disk because 99% of all computers have them and its easier to copy a 3MB installer to a range of floppies than it is to setup some of my users with CDR's and have them burn cd's.

I still use Winzip for some functions because winzip does the spanning, but I see your problems since NSIS is a "single Executable".

Anyway, I'll appreciate it if/when it gets added.

I agree

I use floppy's for distribution as well

My rational is that some minor installations, where my customer only needs (or pays for) the barebones system my installer might only be 3 or 4 MB. Their data comes pre-loaded by their IT department. So I don't really want to waste a 700MB CD for a 4 MB installer. I think multi-disk support, while certainly not life threatening (SP?), might be a real help to people who use large installers with plenty of data and possibly some options coded in as well.

I wouldn't say it has to be done immediately because I don't really need it yet, but I think other installers have it so it might be good to deal with the question now rather than later.

Sincerely,
Jacob Metro
CTO, Systems Analyst

Like I already said, it is already possible using a plugin. Integrated support would make it a little easier, but it has no priority.

Joost,
I've never looked into it, but how would I do it using a plugin? Can I do spanning with ZipDLL? If I could do disk spanning at all, even with ZipDLL or another plugin, it would be worth it I think. Is it documented somewhere? I'm going to go now and read about ZipDLL

I have an idea, i'll try to explain it in english but my english isn't so good.

Make a program that compress each of the files in bzip2, then join the compressed files in a big one and create another text file that contains the positions were each of the small files are in the big one. Then split the big one in multiple files of 650 Mb (1 CD for example) and save the position of the cuts in the text file. A function than decompress a bzip2 file into nsis can't make a big overhead because the code is integrated into nsis.

function decompresBzip2(compressed_file, start_position, end_position, decompressed_file)

compressed_file: the big one
start_position: from the text file (where a file starts)
end_position:from the text file (where a file ends)
decompressed_file: the result of decompress bits from "start_position" to "end_position" of "compressed_file"

Now a simple script can extract a file from a volume.
We know where are the cuts in the big file (are in the text file), if we think that a new cd must be inserted, a dialog box tell us: "insert the new cd". If a file is splitted, copy the first part into a temp path, then append to this file the second part (in the second cd) and then decompress the result.

Well, the main idea is to insert the function decompressBzip2 into nsis (without a big overhead) and a script that extract a file from the volumes reading the text file with the position.

In this way in the first cd we have the instaler (that contains the text file) and the first volume, the second cd only the second volume, ...

What do you think?

Sorry for my english, I can understand it, but never passed the grammar exams.

My idea

This program I have called HJSplit allows you to split objects (preferably a zip file) into sperate specified sized chunks, and then join them back up again.
On split, it seperates them into chunks with the file extension of .001, .002, .003 and so on. If you tell it to split e.g. UnrealTournament.zip, it will split it into seperate amounts as UnrealTournament.001, UnrealTournament.002, UnrealTournament.003 etc
To rejoin them all, you tell HJSplit to target just UnrealTournament, and it does the rest of the work for you.
So, if all UnrealTournament splitted files are in the C:\temp folder, you'd tell HJSplit to target C:\temp\UnrealTournament

See a topic on this here: http://forums.winamp.com/showthread....hlight=hjsplit

1. On the first cd, you have the main installer. It firstly extracts the first chunk of the .zip from within itself, and then it prompts the user to insert disc 2.

InitPluginsDir

SetOutPath $PLUGINSDIR

File "C:\temp\UnrealTournament.001"

MessageBox MB_OK|MB_ICONINFORMATION "Please insert Unreal Tournament \

CD labeled 'Disc 2'$\n$\rClick OK when you have inserted the next \

disc."

2. On disc 2 is the second chunk of the zip, which is then copied to the pluginsdir like so...

CopyFiles "e:\UnrealTournament.002" "$PLUGINSDIR\UnrealTournament.002"

3. After copying all chunks onto the hard drive, it can then automatically re-join the chunks together using a command line version of HJSplit like so...

SetOutPath $PLUGINSDIR

File "C:\temp\hjsplit.exe"

nsExec::Exec "$PLUGINSDIR\hjsplit.exe -j $PLUGINSDIR\UnrealTournament"

4. Then extract from the joined up zip file using the nsis plugin.

Get HJSplit here: http://www.freebyte.com/download/hjsplit/hjspldos.zip

-Stu

The problem is:

I have 3 cd's splitted, i need 650x3 Mb of free space in HD only for the joined file.

You could just say that the installer needs whatever space for...

So much space for UnrealTournament.001, UnrealTournament.002, UnrealTournament.003
Same amount of space for UnrealTournament.zip
Even more space for the final installation!

That could come up to 6gb

-Stu

If you extract directly from the splitted files you don't need the extra amount of space for the joined file.

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

Specifically, I'm a programmer for Cryptic Studios (makers of City of Heroes), and I hope to use NSIS for the installer for our game, but as it stands now, it looks like we'll creep over the size that would fit on one CD, and as it stands, there's no easy way to split a NSIS installation onto 2 CDs (the main issue being that for all of the suggestions above you have to either a) manually choose which files go on which disk, which means no trivial way to just re-build an installer, or b) the install takes up two times as much space on the destination drive while it's installing, which is obviously out of the question).

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).

As a general fan of NSIS, I'd really like to use it for our game (as Sunjammer said, it's good exposure), but only if it won't cause too many problems.

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

Thank you for your time!