New: HomeBank (Sep 03, 2023), Platform 26.2.1 (Sep 17, 2023)
450+ real apps (49GB), 1.1 billion downloads, Please donate.
Jack Haller, Advisor and Father of Our Founder, Has Passed Away
First, thanks for the great software. I've been using it off and on for a few years between home and school.
Is it possible to set the frequency with which the platform checks for updates? Perhaps a monthly or weekly option?
Also, is there a silent install option? Whereby, if enabled, the platform would click through all of the "next" and "finish" buttons in each applications' installation dialog as those apps are being updated?
Thank you for a great platform.
The platform is configured to silently check in the background on each launch by default, only showing you the update window if you have apps out of date. We'll be adding automated checks for hourly, daily, weekly, and monthly at a later date.
All installers run silently unless you have a license agreement you need to agree to. These will be combined upfront in a later release.
If they are not running silently when there is no license agreement (you should never see an installer's finish button for instance), something is wrong with your PC. The installers check to see if the platform is running and they are unable to see it. Sometimes a reboot will fix this. Other times it is due to logical errors on the drive. Twice I've seen it due to a previous malware infection that broke part of Windows. The only fix was to reinstall Windows (which you can often do over the top of your current version without losing data).
This seems to have broken recently. I noticed this on couple of machines where I have Protable Apps installed.
There are several threads on the forum describing this happening to people, but no one provided an exact explanation how silent install works (command line parameters seems to not matter) nor anyone provided any tips for troubleshooting this issue.
There are no command line parameters to worry about. You simply run the updater from the PortableApps.com Platform. The platform must be running for this to work correctly as all installers are keyed to look for it. If you start the updater and then close the platform, the installers will not run silently.
I don't think you are correct.
When installing updates, platform runs individual installers with this command line:
/DESTINATION="C:\PortableApps\" /AUTOCLOSE=true /HIDEINSTALLER=true /SILENT=true
I looked at this using procmon as well as downloaded nsis source code - updater just executes downloaded files from the temp folder.
Something prevents nsis from handling this command line properly, unfortunately, I don't have much time to look into it.
The problem here is that PortableApps installer does not log anything, making troubleshooting almost impossible.
P.S. I am talking here about auto updates when platform starts - so it is running and individual updates are no longer execute in silent mode.
Windows 10, but I have a feeling the OS does not matter.
I wrote the code. The platform must be running. The updater can only be used in conjunction with the PortableApps.com Platform.
I read your code. Didn't like it, sorry.
After looking at nsis code I figured out how this is supposed to work.
- Installer needs to be started with appropriate command line which includes /silent=true parameter
- It checks if file PortableApps.com\PortableAppsPlatform.exe exists in destination folder and that file's proprty has Company Name set to "PortableApps.com Platform"
- checks if executable PortableAppsPlatform.exe is running (without checking if that is correct executable
I don't know why developers went to that length in order to restrict silent installation. This does not seem to be a security, because there is no check here which validates that correct executable exists and running.
More like the reason was inconvenience someone who wants to run silent installs himself.
I now have two Win10 machines - one with silent install working and another one broken. If I have time, I'll see what breaks installer, but it is possible that there are some permission issues...
The only way silent installs is supported is with the platform launching the updater and the updater launching the downloaded installer. Is that what you're doing on the Windows 10 machine where it is "broken"? What's the full install path on that machine? Are there any permissions issues, for instance an external drive with NTFS permissions where the whole drive is not set to Full Access for Everyone?
Please take a look at my other post below. Issue is in FindProcDLL failing to find PortableAppsPlatform.exe process.
Would you please be so kind to explain why this restriction is in place?
Thank you.
I figured at least part of the issue.
For me, the failure is in FindProcDLL when it enumerates all the processes trying to find PortableAppsPlatform.exe process (it is possible to see that is the case in procmon).
With large number of processes it may fail. I see this in some traces I performed and was able to make silent install work by just exiting Opera browser which creates many processes for tabs.
However this is not only the count, what matters - I restarted Opera and grew the total number of processes in the system to >300 and silent install continued to work.
I do not want to debug FindProcDLL. I can, but I don't have time and I also think that PortableApps should NOT prevent users from running silent installs on their own. Then, there won't be need to look into 15-years old C code to see why it is suddenly failing...
So - anyone having similar symptoms - try reducing number of processes and maybe rebooting to test on a freshly booted system.
I haven't been able to locate the reports you're speaking of with FindProc failing with a large number of processes. Could you please share the links?
It may not be the number, it may be the total size of the list of processes being unable to fit into the object that's trying to hold it, perhaps. I was just now able to recreate this issue for the first time ever by upping my processes to 300 but now it's working again with the processes at 350+. I can't get it much higher as Windows seems to randomly kill things off at this point (Opera and Firefox randomly close) and am unable to recreate it a second time. The issue existed for approximately 1 minute.
I'll be working on a fixed installer that will succeed when the detection fails so this won't recur, but that won't fix the issue with the hundreds of installers that are already built.
Thanks for looking into this.
I was referring to a number of posts (I found at least 2 more) which complain about the same issue - updates were silent and all of a sudden, they started to run interactively. I even got to this thread from another one with the same issue.
I don't think anyone bothered to look at this before, not FindProdDLL at least... I got that plugin's source from http://nsis.sourceforge.net/FindProcDLL_plug-in and very quick eyeballing revealed at least one bug - iCb is set to 100 instead of sizeof(aiPID), which means it will fail for sure with >500 process...
As for the fix - most installers are updated eventually and hopefully any updated ones would pick up the change...
I still don't see a point in such restrictions for running silent installs. It would be great if you would communicate with PortableAppsPlatform.exe and check some digital signature, but otherwise this is easily worked around when needed. And extra steps just open up for more issues as we see here.
Ah, yes, it is set to 1000 (think you typo-ed 100) on line 38. I wonder if this was done for compatibility with Win 9x back in 2009 when that still mattered. I'm not a C programmer but I've clunked around enough to be able to update and compile NSIS plugins before back when we were updating them to Unicode so I'll take a better look.
I've got an updated PortableApps.com Installer I just pushed out that switches to treat a failed process check as if the process isn't running. This should alleviate the issue you're experiencing though it will only work for newer releases.
Thank you, John! Hope the fix works.
And yes, I had a typo (100 instead of 1000), good catch.
Looking at the docs for EnumProcesses (https://docs.microsoft.com/en-us/windows/desktop/api/psapi/nf-psapi-enum...), I don't think that API changed much - 2nd parameter is for sure the size of the first in bytes, should have been like that from the beginning 
But I'd think people didn't expect so many processes to be running as we have now. Also article explains (with a typo of its own) on how to deal if number of processes returend is larger than original buffer...
Pro Tip: You can test out the fix by installing the PortableApps.com Installer 3.5.10 when you notice other apps showing the their installers in the updater/app store. To manually do this even when you have it installed, you can select Apps - Install an App to manually select the .paf.exe file. It should auto install but show you the finish page. If you try it with an older installer while the bug is occurring, it will start at the Welcome page.
Ok, great thanks. I will test it out when/if I notice this behavior again!
Visit the Community page
Join our forums
Follow us on BlueSky