Can anyone validate for me that the url (http://portableapps.com/updater/update.7z) called by the updater is hardcoded into the updater itself?
I am trying to build a local repository, and have all the the components I think I need except the ability to make the updater look for a custom url.
Since I do not have the programming skills in delphi to do that part myself, and the url does not appear in any file I can find to manipulate, I will have to write a customer updater to check my repo, download the files and extract them. Of course, I would like to avoid that if possible.
Any pointers?
Thanks
Joe
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on BlueSky
Follow us on Facebook
Follow us on LinkedIn
Follow us on Mastodon
Follow us on Twitter
Are you thinking about doing a locally-mirrored set of the apps so you can distribute them to your local network without having to reach out via the internet to save bandwidth and time? If so, that's something I've been considering adding.
Sometimes, the impossible can become possible, if you're awesome!
It would accomplish the same thing. My primary need is to host a number of applications for our team that I cannot publish to PortableApps.com (All of which I can install and run legally). However, my current code might do what you need it to. My only question is how are you creating your local mirror. If you are using the PortableApps installer and just creating an extracted, executable install on a server, and sharing that, then my code won't help. If you are manually downloading *.paf.exe installers, then what i have may help
Currently I have code that will parse a directory structure and create the update.ini file from the custom *.paf.exe files that I have created, then compress the ini file to a 7z file.
Ideally, the existing portable apps updater would read a list of URLS, then attach custom installers to the bottom of the apps list and we could select them as normal. Or give us a way to swap urls in runtime.
I could be wrong, but a reading of the updater source code ( PortableApps.comUpdater.nsi line 54 ), it looks like this is hardcoded, and I am not sure how to work around it. Looking deeper, there is quite a bit of code
Barring learning delphi i think I will be stuck creating a 'myupdater' paf app that will check my custom ini url, compare to the list of current apps and display any that need to be updated. Then once apps are selected, download and extract them.
I just hate recreating the wheel. Perhaps if we could get the developers to agree to a spec, I could sponsor a dephi developer to code it?
Joe
First, it's NSIS code, which isn't too bad in terms of learning it. It's an odd installer scripting language (yes, I appreciate the irony here).
Second, I have some code started that we were going to use to allow businesses to distribute apps internally. In addition to the standard URL for updates, it would allow another location internally to have a similar updater.ini file that contains all the links to their own internal apps. This would be combined by the updater into a single app list. It could even include required apps that would get installed and updated without the user needing to select them. This was going to be combined with the ability to let businesses custom brand the platform and add additional functionality and such. We never got much interest from businesses, so I never finished it. This was going to be one of the ways PortableApps.com could be self-sustaining. Unfortunate it never happened.
Sometimes, the impossible can become possible, if you're awesome!
hmm.. I see you are right (obviously). I am not sure where I got the idea it was delphi code.
I think I can read the NSIS code reasonably well, which means I can probably figure it out. Let me spend some time tomorrow reading and seeing if I can make sense of at least the ini parsing sections, and work out in my head what a full feature set I can commit to would be and then maybe reach out on Thursday.
Were you thinking "another location internally" would be a file share, another url, both?
Thanks
Joe
This was planned to be a paid feature to allow OEMs and other partners to offer a co-branded platform (aka their logo in the menu in addition to ours) with custom theming and links to their support, store, etc. It would also allow custom app lists via URL to their own apps as well as blacklisting specific apps/categories in our app store or only allowing apps/categories on a whitelist. We would manage/approve this list of apps and only a certain number of installs would be permitted based on the licensing.
In addition to this, we were debating allowing companies to update internal apps via an INI and the installers stored on a file share for free. Handling it via a drive letter-mapped file share only would ensure a third party couldn't distribute the platform in a modded form with links to a pirated/warez/unsafe app store. It would also ensure that a malware app couldn't infect a users existing platform and add in their own app store with malware etc.
The existing code I was working on is mostly for the former feature as we came close to making deals around it that would have helped fund development.
Sometimes, the impossible can become possible, if you're awesome!
John,
I spent some time working on these questions yesterday, and it all seems doable. At least I can get some functional code working and move the ball forward a bit.
As I have been working to understand the updater code, I have been making a wish list of options/features I could see being useful. I would love to walk through the list with you to see where we have overlaps, or where I am going off the reservation as it were. As well, getting any code you already have mocked up would be great to have.
Is it easiest to do through a thread here, an email thread or perhaps a call?
Thanks
Joe
Correct me if I'm wrong, but I'm guessing including bittorrent protocol in the PortableApps platform would be a general solution that would favor a LAN "cache" over more distant and slower sources. It would be more robust against downtime and outages, and it would have all the other benefits of bittorrent too.
Including bittorrent protocol would make it far more likely the PA.c Platform would be blocked by universities and companies, though.
Sometimes, the impossible can become possible, if you're awesome!
I think that would only apply to the protocol, in most cases. Also, I'm guessing blocking is much less likely to affect local LAN connections, since protocol blocking is usually applied only at the WAN gateway firewall, not at LAN routers, switches, and hubs. If so, then this application should still work most of the time, even when bitttorrent is blocked.
Of course, the PortableApps platform could still fall back to your local cache code next, and if that fails too it can fall back again to the ordinary update system currently being used.
I mean including it at all would make it more likely for organizations to ban the PortableApps.com Platform full stop either via organizational rule or technical blocking. Not just blocking the torrent abilities.
Sometimes, the impossible can become possible, if you're awesome!
Oh yeah, don't do that. Wait, actually, that sounds bad, but I think maybe it creates an opportunity for business development for the PortableApps Suite. The bittorrent functionality could be included only in the custom versions that organizational users request.
It might be possible to make it available to developers, beta testers, or a few individuals while keeping it off the radar of organizational rule blocking and technical blocking. For example, a version provided to individuals could require use only on the recipient's privately controlled PC's and networks. If there is a programmatic way to enforce that restriction, it would make it a lot safer to let a few people use it without getting it noticed and banned on institutional systems if somebody tries to break the rules.
Or, maybe it's not worth the risk. In that case, the business development possibilities might still look good. Do organizations auto-detect and auto-add bittorrent-protocol-using software to block lists? If yes, then maybe the business case isn't as good as I thought.
I can't speak on the prevalence of it right now, but at one stage not too many years ago many Australian ISPs would actively give torrent-based traffic lowest priority and some would even shape torrent traffic to an annoyingly slow pace. I assume there may be other places in the world with similar issues.
The fact that it isn't blocked would would mean a fallback would never take effect, and anybody on an ISP like this would have a significantly harder/longer time to update their apps.
I have often noticed when a torrent download is much slower than a direct download. That situation can be dealt with in straightforward ways. For example, speeds can be tested and compared pretty easily, even in cases where continuously changing speeds occur (like in mobile or congested networks).
One thing that isn't widely known that I have noticed is some ISP's avoid responsibility for throttled speeds by not throttling for the first 30 seconds or few minutes of a burst of network activity. That makes it so ordinary web page use is very fast, small downloads are unaffected, and internet speed tests show the highest possible results. But, after that brief amount of time, speeds drop dramatically, and the user is encouraged to wrongly blame the download origin for the slow speeds.
LAN torrents are unlikely to be affected by throttling, but I suppose anything is possible. The "brief non-throttling" trick is very effective at reducing the impact of bandwidth hogs, in all situations.