Suppose I want to make a program portable, which is a Freeware but not Open Source. Normally I need in this case a permission of the developer of the program. However, I've read here several times in the forum, that it would be with an online installer possible to make a program portable without the consent of the developer. Personally I consider this possibility for something bizarre, because I am of the opinion, that the main feature of an online installer is to make the size of the installer file (*. paf.exe) smaller. Is my assumption so far correct?
New: Run-Command (Dec 2, 2024), Platform 29.5.3 (Jun 27, 2024)
1,100+ portable packages, 1.1 billion downloads
No Ads Nov/Dec!, Please donate today
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
Making the PAF smaller is pointless as the user has to download it eventually. The whole point is licensing or hosting requirements.
Sometimes, the impossible can become possible, if you're awesome!
For myself it is of course very important to know whether I just need to host a small installer (space saving). Take as example the app Chrome browser. You still have not answered my main question, why in the case of an online installer this is meaningful in respect to licensing.
Online installers are for apps you cant distribute.
It has to download stuff during install, so making the size smaller at first doesnt really pay off for anyone if the user has to download stuff later.
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
Does this mean that I can offer a portable program with an online installer, if I do not receive a permission from the developer? The reason for this possibility is apparent that now the user downloads the program itself. And it is legally permissible.
You are right, that is the common procedure.
From a legal point of view it should be ok but keep in mind that maybe you offer a program to take actions not expected or desired by the original apps developer. I think you have to deal with certain legal issues if they apply to the specific app like displaying a EULA if the app's own installer does that as well. So that the user is informed about his rights and duties concerning that app.
I am not shure if an online installer would be possible if a license explicitly prohibits the use on more than one computer but maybe that would still fall into the responsibility of the user.
I would say, take a look at the apps license and if nothing comes in the way, go for it.
Regarding the file EULA.txt I suspect, that I must extract this file from the appropriate setup.exe file of the original program. Afterwards I paste the file EULA.txt in the folder Other/Source. Is this procedure so far correct?
Regarding the MD5 hash I think, that's necessary to download the setup.exe file, if the developer not offer this MD5 hash on his website. Afterwards I figure out this MD5 hash by myself.
Now I will consider a concrete example. Assuming I want to make the program named "MyApp" portable (the setup.exe file is named myapp.exe).
When I extract the file myapp.exe (e.g. with the Universal Extractor v1.6), I may get the following files and folders:
Assuming I need the file "file1.abc" and the folder "folder1" but not the file "file2.def" and the folder "folder2". The file "file1.abc" and the folder "folder1" should be contained in the folder App\MyApp. To reach that goal, I've created the following code inside of the file "installer.ini":
I assume, that this code will realize my intention.
I am not shure, but I think, you also need a
AdvancedExtract2To=App\MyApp. And I can not say for shure if ** works for a single folder as that normally is used for the whole archive. I would expect a single * here.If you only need to delete few files or a single folder, that could perhaps be accomplished more easily with custom installer code. That depends on what changes more in future builds (does the part to exclude vary or the part to include).
Do you do PicPick at the moment (I'd be really glad to see it continued
)? You could have a look at prappers installer.ini - just to verify your findings (even if the contents of the archive have changed).
In the moment I work on PicPick. I use this wonderful program since a lot of years (I 've make it portable with help of the Universal Extractor v1.6 and some little adaptions).
Regarding the fact, if my code is valid or not, I will try it in brief. Unfortunately has prapper removed the downloadlink for PicPick. But the code AdvancedExtract2To=App\MyApp is not necessary, because I've already a line with AdvancedExtract1To=App\MyApp.
Nice, I use PicPick as my standard screenshot tool, too.
Should not be too tricky as PicPick is portable already by design, can't wait to test and use it. Thanks for picking that up!
If it's any help:
http://sourceforge.net/projects/prapper/files/picpick/
Thank you for this link. But can you explain me the reason, why you have inserted in your file "installer.ini" the following code:
Is that not a contradiction, because the folder picpick is changed during an upgrade?
Without that entry, when the installer fails because the app is updated, the user is left with no app (App\picpick has already been removed). I prefer this though -
App\AppInfo\installer.ini:
Other\Source\PortableApps.comInstallerCustom.nsh:
!macro CustomCodePostInstall ${If} ${FileExists} $INSTDIR\App\picpick_NEW\picpick.exe RMDir /r $INSTDIR\App\picpick Sleep 100 Rename $INSTDIR\App\picpick_NEW $INSTDIR\App\picpick ${EndIf} !macroendAdopted I will use your code in the file installer.ini. In order to use this code, however, it's necessary that I first create a folder called picpick_NEW. In this folder will extracted the necessary files and folders of the app. But what sense makes then an additional folder called picpick? This folder would not be used, i.e. it is total needless.
I've detected the following during an update from my version PicPick Portable Test 1 to Test 2. First the content of the folder picpick will removed, i.e. the folder picpick itself stay maintained. Afterwards will extracted the new content in the folder picpick by the installer.
Based on these findings I am convinced that it is not necessary to preserve the folder picpick.
May I bring further enlightenment?
As prapper stated, his code setup is only necessary in case the file to download is not availlable (because it has been updated, renamed, moved on the server etc.).
The problem with the PA.c installer is, that it first deletes the app folders content and only afterwards checks, if the download is valid.
So: If the file to download is not availlable, the installer will destroy the previously installed app.
prappers code prevents just that. It preserves the app's folder (picpick), extracts the contents of the downloaded file to a temporary folder (picpick_NEW in this case, automatically created). This is done by the installer with the installer.ini.
Afterwards the installer checks, if the extraction was successful (it would not be, if no valid download file was downloaded) and only then deletes the picpick folder and renames the picpick_NEW folder to picpick. This is done by the installer with the custom code.
So: the already installed app will only be deleted, if the download and extraction was successful.
I would be glad, if such a functionallity would be integrated in an upcoming release of the installer. It would only need to switch the order of actions to first download and then delete and extract.
@prapper: nice code. May I use it on my Nemp dev test?
First thank you for your understandable explanations. But for me one question remains unanswered:
Are you really sure, that in this case the installer remove the previously installed app? It might also be possible that in this case the installation is canceled. Then also stay maintained the previously installed app.
I have now altered the DownloadURL in the file installer.ini. I have applied a false URL. Indeed now is the content of the folder picpick deleted. Therefore is your assumption correct
Yes, because once again it was no assumption... SCNR
That's the wrong place to fix it. It should be fixed in the PortableApps.com Installer. Feel free to submit a patch to fix it in some way, but I would say that including code to avoid this in your own app causes trouble; the first technique may cause it to hit exactly the same problem that the removal of the App directory is designed to avoid, while the _NEW plus custom code approach makes it slower and harder to maintain and is obscure. Such bits of code as this are what we explicitly try to avoid with the PortableApps.com Format, Installer and Launcher.
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
I pointed to this issue/bug several times in the past. As this applies only for online installers and therefore mostly for development tests, I don't know if or how it should be fixed.
I feel not capable to alter the installer source or to submit a patch, especially because I don't know the design decisions made, like: why is the order of actions like it is atm?
I don't know what functionality might brake, if the order would be altered.
If it would be possible, fine. But if not, that is the only solution at the moment to keep develeopment test apps in use that otherwise could break because of not proper maintained versions. I encountered this every so often and to me it is much more complicated/obscure to have to make a backup of an app before updating simply because the installer might fail ungraciously.
depp.jones: You may not feel capable of making changes to the Installer, but I personally relish the challenge. So, here's what I've got so far.
https://portableapps.com/node/30992
Not sure if that fixes it for sure, but it's worked in my limited testing so far.
When I read through your post, then I have to say, unfortunately, that you present only hypothetical and potential objections. You often use words like should, would ... I have analyzed the code of prapper in detail and it is logical and clear. You only have mentioned, that this code is obscure. But you don't offer any facts, why is it so? Let me compare this procedure with that of mathematics. If you place an assertion, you must prove it. Only then can arise here with clear arguments a fruitful discussion.
Let me finally make a remark. Often in the past have unconventional solutions violated against established thoughts. And exactly these unconventional ideas were the solution to a problem.
Hi tapsklaps, Chris' objections are fully legitimate. Even if prapper's workaround is fully functional it makes things more complicated than needed. As the whole PA.c concept is to establish a standard, it is better to enhance the underlying tools than to tinker around with makeshift solutions. Latter are ok as long as there is no other possibility, but fixing the installer in general definitly is the better way to go.
The whole idea is to do packaging in a way that they are easy to maintain and the combination of PA.c installer and launcher was established to ensure that. We had custom launchers written in different script languages some time ago and - while they work (sometimes more specialized and eventually better) - consider the mess to maintain the lot of different approaches when apps become official. Over the years some if not many developers left PA.c and atm only a small bunch of people maintain all updates. The biggest workload is left to John and I don't think he is eager to learn every app's speciallity that might cause issues during updating...
(btw. take that into account when doing special solutions like the language switching in tomahawk when there already is a standardized way
)
All that can eventually be ignored if a package should always stay in dev test state, but the simpler an approach the less issues are likely to sneak in.
For the special case of PicPick, it does not mind as it possibly will never become official and the custom code is so simple that it does not make it overly complicated (I think, Chris errs with his statement that it slows down the update process as merely similar actions are executed but in a different order. The installer's instructions itself carry no weight).
The concern of Chris is perfectly understandable to me. However, since the PAI can not cover all possible cases, more specific solutions will be needed always. Accordingly, these remain workarounds as of prapper always an inevitable ingredient in the development of portable apps. In addition I am of the opinion that Chris as one of the main developers of the PAI should take such workarounds as of prapper as an occasion, that he revise the code of the PAI itself. Because as you have mentioned in your other post correctly, it is far too opaque for other developers to make corresponding changes to the code of the PAI.
In respect to your comment on Tomahawk I would like to point out, that the fact of an existing standardized solution not necessarily have to mean that new solutions are worse. On the contrary such solutions may well be even better because they are clearer and easier and easier to implement. Ultimately an already standardized way is not the last word and is also subject to continuous development.
Your assumption, that PicPick may never reach the release status, I think is questionable. If I compare this program with such as Frhed Portable, I'm firmly convinced that there is a significantly higher demand after PicPick. Also I am convinced that PicPick compared to many other screenshot programs offer significantly more features and is also constantly evolving. Insofar it would be very unfortunate if this brilliant and high-quality program would not achieve the release status (which I of course hope not ).
As wiziple (the developer of PicPick) has spoken distinctly against giving his permission for packaging PicPick as portable app here earlier, I doubt it will be included in the official apps list. But who knows, maybe John will change his opinion and allow more online installer apps in upcoming releases.
For standardization: I consider that the most important concept of PA.c. You can always write better, more specialized, feature rich, whatever, solutions by yourself. You can even write binary launchers from scratch in the programming language of your choice if you like. But that is completely against the whole idea of making it simple. PA.c has evolved to the state it has now and having standard solutions is one things that have crystallized in this process.
But we drift towards OT (again
)
After my understanding is due to the online installer no permission required from Wiziple. The reason is that the user must explicitly accept the EULA and then will download the program itself. A good example for this legally permissible method is the program µTorrent. µTorrent is also Freeware but not Open Source. And µTorrent will be offered about an online installer.
Perhaps we could for a better understand the whole thing explain as follows. The user has of course the possibility to go on the website of Wiziple and download PicPick. Afterwards it's completely legal, when I give him some instructions how he can make PicPick portable.
You missed the point. This is perfectly ok for a development test build but John is reluctant to releasing online installer apps. µtorrent and chrome are the only exceptions (afaik) at the moment just for the reason that they are blockbuster apps. I think, the developer's objection does not help it either.
But don't take my word for it, I don't know what John has in mind for the future.
Your argumentation is obviously inconclusive. First, it may not be that for certain programs like µTorrent and the Google Chrome browser an exception is made. Either it is legal or not. That's simple logic. And also programs in Dev Test status are already officially available for download. Only not so many users know of this facility.
Again, you missed the point. It is no matter of legality. As explained (in the beginning of this thread and in numerous topics in the forum) it is considered legal to do online installers for freeware apps where no permission is granted. But the decision to officially release an app is made by John and he has said several times that freeware apps that are online installers because there is no permission by the developer don't get officially released. They are bound to stay dev tests forever (like PicPick supposably).
That's the only thing I tried to explain to you when we (again) began to go round in circles... I become weary to discuss simple things with you. It is as usual no matter of being right or wrong but simple facts. John clarified his point of view and that's it. You could try to convince him if you like, but that is another story.
Its not about legal/illegal. If John said he wont release other apps as online installers, that has nothing to do about legal or not.
So for dev tests it might be ok, but not for officially released apps.
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
Who contacted the publisher on this, btw? I wonder if they are aware of the illegal portable sites repackaging it.
As mentioned, we won't be doing any additional installers except where absolutely necessary. jPortable, for example, uses an online installer because while it is permitted for us to download and portablize Java as we do, it is not permitted to repackage it. Oracle is fine with us doing it this way and our selection of name which doesn't infringe on their trademarks.
This is the final word on the subject. You're free to do what you want on your own, but an online installer for an app like PicPick where the publisher has expressed his disapproval for a portable app will not be put in the Portable App Directory.
Sometimes, the impossible can become possible, if you're awesome!