The new PortableApps.com Installer and Format has been released:
https://portableapps.com/development/portableapps.com_format
https://portableapps.com/apps/development/portableapps.com_installer
I've been making a lot of progress on finalizing PortableApps.com Format and the PortableApps.com Installer for generalized use. As discussed previously, the installer is switching to an INI-based configuration so that publishers and devs won't need to write any code to get an installer.
Here's what the appinfo.ini file will be looking like:
[Format] Type=PortableApps.comFormat Version=XX [Details] Name=FileZilla Portable UniqueName=FileZillaPortable Publisher=FileZilla Team & PortableApps.com Homepage=PortableApps.com/FileZillaPortable Category=Internet Description=FileZilla Portable is the popular FileZilla FTP client packaged as a portable app, so you can take your server list and settings with you. Language=Multilingual Trademarks= InstallType=Multilingual [License] Shareable=true OpenSource=true Freeware=true CommercialUse=true [Version] PackageVersion=3.2.4.0 DisplayVersion=3.2.4 [Plugins] PluginsPath= [Control] Icons=1 Start=FileZillaPortable.exe
The new fields as compared to the existing appinfo.ini are:
UniqueName - This is a globally unique name. For apps created by the publisher themselves (most preferred method) or packaged by PortableApps.com (second most preferred method), it will usually be the app's name with no spaces (though some apps like Mozilla Firefox, Portable Edition are shortened for legacy and readability reasons). For apps published outside of PA.c and not by the original publisher, it will be the same format but with a dash and then either their PA.c username (for personal dev's work) or domain name (for other entity's work). For example, if user JimBob were to do a custom FileZilla Portable package with some additional stuff, it would be FileZillaPortable-JimBob. This will be used in the app's directory name and by the updater later.
Language - This is the language that the app is available in. It will primarily be used by our launchers for single-language apps (like Firefox and OpenOffice.org) so we can compile one launcher with all supported languages and it can check appinfo.ini to see what language it should display to the user.
Trademarks - If there are trademarks associated with the app, they should be listed here. These are a part of the installer comments and will be displayed in app details within the platform later.
InstallType - This filed will be updated (and created if necessary) at install-time by the PA.c Installer itself for apps with optional components. For example, with FileZilla Portable, if the user doesn't install the additional languages, it would be InstallType=English Only. If they did select to install them, it would be InstallType=Multilingual. It will be displayed in app details in the 1.6 platform release and will be used by the installer when launched from the menu or updater during upgrades so the user doesn't need to reselect the components.
PluginsPath - This is the path for plugins from the current installer config. It's excluded from space calculations. If empty, it's assumed none.
Other than that, no additional info is needed to create the installer for many apps. The installer will assume that it's making sure the file listed in Control-Start is the one that should be closed. The installer will assume the installer source isn't included, that the app and other directories should be removed. It will include a license page if it finds eula.rtf or eula.txt in the Other\Source directory. It will include custom code if it finds the custom code file in Other\Source (and search it to determine if you need ConfigRead, VersionCompare, etc). The one thing I'm debating is whether it will default to English-only... or multilingual with all our supported languages. And I'd love opinions on that.
If you do want to make additional customizations, you can with an INI file called installer.ini within the App\AppInfo directorty. The defaults for it would be:
[CheckRunning] CloseEXE= CloseName= [Source] IncludeInstallerSource=false [MainDirectories] RemoveAppDirectory=true RemoveDataDirectory=false RemoveOtherDirectory=true [OptionalComponents] MainSectionTitle=$APPNAME Portable (English) [Required] OptionalSectionTitle=Additional Languages OptionalSectionDescription=Add multilingual support for this app OptionalSectionSelectedInstallType=Multilingual OptionalSectionNotSelectedInstallType=English OptionalSectionPreSelectedIfNonEnglishInstall=true [Languages] Multilingual=false Language=English ENGLISH=true AFRIKAANS=true ALBANIAN=true ARABIC=true BASQUE=true BELARUSIAN=true BOSNIAN=true BRETON=true BULGARIAN=true CATALAN=true CROATIAN=true CZECH=true DANISH=true DUTCH=true ESTONIAN=true FARSI=true FINNISH=true FRENCH=true GALICIAN=true GERMAN=true GREEK=true HEBREW=true HUNGARIAN=true ICELANDIC=true INDONESIAN=true IRISH=true ITALIAN=true JAPANESE=true KOREAN=true KURDISH=true LATVIAN=true LITHUANIAN=true LUXEMBOURGISH=true MACEDONIAN=true MALAY=true MONGOLIAN=true NORWEGIAN=true NORWEGIANNYNORSK=true POLISH=true PORTUGUESE=true PORTUGUESEBR=true ROMANIAN=true RUSSIAN=true SERBIAN=true SERBIANLATIN=true SIMPCHINESE=true SLOVAK=true SLOVENIAN=true SPANISH=true SPANISHINTERNATIONAL=true SWEDISH=true THAI=true TRADCHINESE=true TURKISH=true UKRAINIAN=true UZBECK=true WELSH=true [DirectoriesToPreserve] PreserveDirectory1= [DirectoriesToRemove] RemoveDirectory1= [FilesToPreserve] PreserveFile1= [FilesToRemove] RemoveFile1=
The above is basically from the current Config file but in INI form. The PreserveDirectory1=... style entries are also similar but will allow for unlimited entries instead of the current 10. This will alow us to avoid custom code in more installers, making life easier later. I may even ditch the PreserveDirectory1= entries and just have it be a list of directories.
That's about it for right now... any thoughts?
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
I'm interested to know though whether you're using a helper executable which makes an NSH file, or something like at http://forums.winamp.com/showthread.php?postid=2072602?
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
Having now had a chance to read it more thoroughly (I had to rush off yesterday) I can comment.
I think that a multi-lingual installer is good, but thinking from the perspective of an end user, they might then be confused if the base application doesn't support the language they specified. How's that for a comment, it doesn't help you at all to decide which way to go
(Noting your "looking for VersionCompare" etc. stuff, I presume then that you have made a helper executable which is run by the installer to define its content. That's likely better than the batch "for" technique anyway, which won't work on Windows 98 and is limited in its capacity.)
I'm also thinking about how this can be worked in with the generic launcher-to-be. I reckon that the launcher content should go in App\AppInfo, not App\Launcher... anyhow, I've made a generic launcher myself, which at the moment can do move-move of files and automated registry backup, and gets fed with an INI file like this (fully functional example):
Or like this (fully functional example except for personality switching in the user's INI option which my Code::Blocks Portable launcher does):
Would you mind if I published what I've done so far?
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
We can pick and choose stuff for our main launcher.
Sometimes, the impossible can become possible, if you're awesome!
I'm at school right now, but I'll upload what I've got when I get home. It comes with the sample INI files for 7-Zip and Code::Blocks in its pretty complete documentation HTML file.
I actually abolished all manual labels and used LogicLib all the way through.
Yesterday I put together an arbitrary environment variable section, with optionally {&} at the start or end to signify the current variable content (prepend/append), and during another 20 minutes I got to work on it today I added an option to have a contained TEMP directory which can be cleaned up, as I use in gVim Portable which leaves downloaded files and spelling files in TEMP and never cleans up.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
Thank You for the language and the plugin entry, this will make the live easier especially for the OpenOffice.org Portable packages but for the Updater too, cause this will give us a way to offer plugins for existing packages too (if we want to do this)
Paid for Software more or less?
What You need is OSS!
Yeah... adding on to what Chris said... how exactly are you planning on doing this? Obviously the installer can't read INIs until it's compiled. And how do you plan on editing an NSIS script file with another executable? (I've been trying to do that for a while).
Also, this is just my opinion but... we should finally bring back up the topic of having a choice to install help files, source code, etc.
Just saying, some guy with maybe 100 apps could save a lot of megs that way.
And one more idea, the folders in the "PortableApps" folder should have a destop.ini file, that shows the app's icon.
You know, to add more pazazz (hope I spelled that right) to the suite and make it easier to manually manage and remove Portable Applications.
It wouldn't be hard to do, just make the desktop.ini point to the appicon.ico in the "App\AppInfo" folder
You can execute run-time commands at compile time by using the !system command with helper executables. You can even go so far as to write the source for these helper executables using
and then compiling it with
If you want to see an insane overuse of this tactic, check out my post over at the WinAmp forums http://forums.winamp.com/showthread.php?threadid=305102 I attached a script on my third comment that actually contains no run-time code and acts entirely as a compile-time build script using the method I described. So that part at least can be done.
Quamquam omniam nescio, nec nihil scio.
The PortableApps.com Installer app will be a simple wizard interface bundled with a minimal NSIS installation with all necessary plugins. It is an entirely self-contained portable app. You point it at a folder and it generates the installer for that app based on the info in the appinfo.ini and installer.ini.
Help and source will not be optional. It makes the installers more complicated and saves almost no space. The help files are required by the format spec and the platform. We won't be including installer code in future releases (it's actually not in the current Firefox, for instance). Firefox, which has the most source files in it, all told is only 88K.
Sometimes, the impossible can become possible, if you're awesome!
So if I understand, you are saying that the new installer compiler system will be released as a .paf.exe that, when installed and run will operate as a wizard frontend for pointing makensis.exe and the PA.comInstaller at the correct folder containing the app and going from there rather than putting the PA.comInstaller.nsi in the source folder of the app? If so, I say thumbs up. Especially for newer developers, having a GUI takes away a lot of the intimidation at diving into a new project as well as stopping them from editing the installer incorrectly. It will also help to further enforce standards, and I really like the idea of all of it being INI driven as well.
Quamquam omniam nescio, nec nihil scio.