Repository Applications Update Information

Keep in mind if an App uses %ProgramFiles% of any kind then it's not really a ppApp and should instead be converted back to a ssApp, even if it's not using a Setup it will be lost with a OS re-install, so it's not a ppApp, so SetupS is just "encouraging" you to do it the right way

 

So you're saying, use a ssApp.7z instead? Some original installers are like a box of maladies, but I do admit that if I can help it I don't create .exe installers from scratch if I can help it. Most of the time, it works to just add the runtime or other files in the app dir as you know, but for those pesky x64/x86 files with the same names, where the main exe is programmed to look in certain directories for them...

 

Well, strictly speaking, even if "ProgramFiles% was completely empty (for example, from a fresh install), then Trouba's ppApp "patch" would still populate it with the necessary files -- as that patch-file is/should be already contained in the ppApp's Install-to path (%AppPath%) -- after all, this was how ppApps were designed ...

What he said.

 

Freezer, that %SystemRoot% with the subfolders in the patch archive worked great.

Glenn: could you post an example of that script that only blocks a given .exe in the app directory, say, Photoshop.exe? Just making sure I understand it.

 

LOL, you might want to change that to %SystemDrive% because if I ever get around to fixing the bug with %SystemRoot% ... well, your patch would then extract to "C:\Windows" instead

 

Haha, sorry, I did indeed use %SystemDrive%!

 

To do an Unknown EXE:

Code:

@echo off
setlocal enableextensions
cd /d "%~dp0"

for %%a in (*.exe) do (

netsh advfirewall firewall add rule name="Blocked with Batchfile %%a" dir=out program="%%a" action=block
exit
)

To do a Known EXE

Code:

@echo off
setlocal enableextensions
cd /d "%~dp0"

netsh advfirewall firewall add rule name="Blocked with Batchfile %~dp0Photoshop.exe" dir=out program="%~dp0Photoshop.exe" action=block

)

Keep in mind %~dpo has a trailing backslash, so DON'T add one in to your path (%~dp0\Photoshop.exe) <- This will fail to block it.
I've not tested but you might be able to get rid of the 2 %~dp0 if netsh uses the current path to add them, if it works with it, leave it, but if it fails to block, then try without them.

-EDIT-

I am thinking it would be best to block the exe name without the path, in case the same EXE tried to run from a modified drive/path, so try:

Code:

@echo off
setlocal enableextensions
cd /d "%~dp0"

netsh advfirewall firewall add rule name="Blocked with Batchfile Photoshop.exe" dir=out program="Photoshop.exe" action=block
)

 

Thanks a bunch, will test.

 

https://www.tenforums.com/network-sharing/43084-how-block-multiple-exe-files-windows-firewall.html

This shows with full paths, so I now think you do need the full path.

 

I just tried your second example, the Known exe. It works!

EDIT:

Upping an app (Helicon) to repo right now which includes it.

 

How would you add multiple known exe's in one script? For example, SoftMaker Office textmaker.exe, planmaker.exe, presentation.exe?

EDIT:

Ah, figured it out:

Code:

@echo off
setlocal enableextensions
cd /d "%~dp0"

netsh advfirewall firewall add rule name="Blocked with Batchfile %~dp0PlanMaker.exe" dir=out program="%~dp0PlanMaker.exe" action=block

netsh advfirewall firewall add rule name="Blocked with Batchfile %~dp0Presentations.exe" dir=out program="%~dp0Presentations.exe" action=block

netsh advfirewall firewall add rule name="Blocked with Batchfile %~dp0TextMaker.exe" dir=out program="%~dp0TextMaker.exe" action=block

)

 

Shotcut ppApp is now dual-arch. Unpacked dirs for the x64 and x86 versions are over 500mb each, but when combined as dual-arch archive identical files in each get compressed efficiently, making the final ppApp.7z archive only a little larger than the x64 version alone.

 

You needn't have gone to all that trouble with 7-Zip. Just install it as a ppApp with SetupS -- it'll take care of all the details for you.

 

That reminded me, I hadn't updated the ppApp versions of 7-Zip and WinRAR in ages. I thought no one was using those and even I who liked the ppApp versions just installed the ssApps instead. But I updated the ppApps and am switching back to using those, instead.

 

Oops, the WinRAR ppApp lacked license, fixing it now.

EDIT: fixed

 

FYI, I had noticed that the ppApp for "Bulk Rename Utility" wasn't registering the dll for it. It was missing the info for that, so I added it back in "v3.2.01" (and v3.1.0.0, I think) and re-upped the corrected apz.

 

Ah yes, context menu for it. I don't use it much so I didn't even know it had this.

 

Oh yes, BRU is a must have utility for me.

 

Spencer ppApp just uploaded. It's a simple, portable XP style start menu for Windows 8, 10 (also works on 7). I made it into a ppApp that taskbar-pins it. Might come in handy.

 

MediaHuman YouTube to MP3 Converter is apparently freeware now. Foxit still doesn't appear to be releasing "clean" installers for Foxit Reader anymore, and instead only offer "prom" (promotional content) installers, meaning it will try to install Foxit PhantomPDF. I haven't looked into whether this can be circumvented with switches, or if they do still offer the "clean" versions as well. Their download links now can't be guessed anymore as they put unique identifiers in the addresses of each .exe. So even if you happen to get links for a clean version one time, the next update to the app the links are different again. They want to deny access to non-promotional installers and probably keep those available only for corporate needs (if they even make them anymore at all). So I tried to keep the Foxit Reader ppApp as full-featured as possible, with it only lacking ConnectedPDF and Creator, as these either require running processes or installation of drivers.

 

I've upped a slightly modified qBittorrent ppApp that will update the client and preserve its current settings and data. (Or if never installed before, will initialize it for the first time)

I'm unsure what torrent client Trouba uses; so he may not be aware of the problem -- which has been an ongoing issue with qBittorrent for a while now. It doesn't matter how you update it ... whether via the internal updater, downloaded from their website, ssApp, even the ppApp would reset the client -- everything: the settings and your torrent data!

The only fix the qB developers recommended was to manually back up the settings, do the update, then manually restore the settings. That is if you could figure out where the settings is located (both AppData\Local and AppData\Roaming) or use something like Hekasoft Backup & Restore.

And it's unfortunate since it turns out to be such an easy fix. I wanted to see how PortableApps.com did the updates and preserved the settings and data. I'd contemplated using theirs except they don't have an x64 version for dual-arch installing, etc. like Trouba's ppApp. So instead I incorporated their way into Trouba's ppApp -- all that was done was removed the qBittorrent.ini from the app folder.

 

Yep, this is an issue as including some config files will help to pretweak some apps, not check for updates, etc. -- until it's actually desired that the app does that The emphasis had always been on clean OS installs and new app installs but for some apps it's just too complicated and we don't want to overwrite personal usage settings in case of a regen or what have you. Personally I use qBittorrent but I use it very infrequently so I am not even aware of issues like this.

 

No, it's not your ppApp's fault. It was how the qB developers designed their updates with literally no way to preserve your settings.

For example, I can download and install the updates for Filezilla -- either internally from within Filezilla or via their website -- and it preserves my settings after the update.

 

I expect if Freezer uses a script (that is ordered to run before installing) to rename the current qBittorrent.ini to qBittorrent.bak and after it's installed/updated that it delete the new qBittorrent.ini and rename the qBittorrent.bak to .ini. Something similar to that? - I might go download and see for myself

Code:

rem Mkdir "%AppData%\qBittorrent\"
rem #Is_x64# Copy "%AppPath%\_x64\qBittorrent.ini" "%AppData%\qBittorrent" /y
rem #Is_x86# Copy "%AppPath%\_x86\qBittorrent.ini" "%AppData%\qBittorrent" /y
del /F /Q "_x64\qBittorrent.ini" >nul:
del /F /Q "_x86\qBittorrent.ini" >nul:

well you have remed out the feature and delete the portable backup, so I don't know how the settings would persist after a fresh OS install. It's no longer portable and uses the %AppData% version, I see no benefit for changing this, would prefer my method I thought you would use