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.
Archive: Split to volumes...
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
:up:
[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."
CopyFiles "e:\UnrealTournament.002" "$PLUGINSDIR\UnrealTournament.002"
SetOutPath $PLUGINSDIR
File "C:\temp\hjsplit.exe"
nsExec::Exec "$PLUGINSDIR\hjsplit.exe -j $PLUGINSDIR\UnrealTournament"
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!
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 virtlinkThe 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).
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.
Part of a post originally posted by WastelandI 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 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).
Part of a post originally posted by WastelandWhen you'd only have two installers, you could have the following problem:
(...)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.
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 kichikMeaning that the -in memory loaded- executable may need it's own executable file. So it isn't unused anymore.
(...)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.(...)
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...
Archive: Split to volumes...
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:
http://nsis.sourceforge.net/Multi-volume_Distribution
-Stu
Re: Any news on Splitting into Volumes?
Originally posted by BigBoosterIf 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?
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?
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.
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.
http://nsis.sourceforge.net/Multi-volume_Distribution
-Stu
Originally posted by Mr InchesWell, hard to answer.
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...)?
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!