Ricktendo had gone to repacks.net but has largely stopped updating apps, although a few there have been updating a bit, but not much recently. Luckily there is one more person (a german guy) who still makes updated .net framework .4x installers for Win7 and such, I linked to his thread on a forum in my latest .net 4 ssApp.
Saddens me to hear that so many have quietly left the room. And I know how they feel. Windows 10 can be so deflating. I found this (on WinCert.net): WPIW & Kelsenellenelvian retiring
Turns out this may not have been a bug with SetupS after all. I cannot get it to do it now matter what I try. I think it might've been a one-off fluke. SetupS gets its System Variables directly from Windows so perhaps at the time they weren't resolving properly..(?) I don't know. Nothing to fix if I can't duplicate it.
Though I have found a bug with SetupS, a real one this time. If "Refresh Explorer" is enabled, then it will create a Desktop shortcut. Also, BP has discovered bug with the Build-function for ssEditor; plus some corrections to the help-file. I've also discovered that the %AddonInstaller% tool doesn't work with Window 8.1 -- and likely Windows 10 as well. I still need to do some more testing but so far these apps no longer install with SetupS (on Windows 8.1): Kels.Universal.Silent.Switch.Finder_v1.4.1.1_ssApp Vista.Mouse.Cursors.Addons_ssApp
I have a feature request - ssEditor/Builds Menu; Make Archive Deployment Package (.apz/.pgz) I would love for this to be; Make Archive Deployment Package (.apz) Make Archive Deployment Package (.pgz) I always make my applications .apz, but I always leave my ppGames as ppGame.7z .ppg .png .jpg .ico inside the folder, I compress via the Send To / ssEditor (AutoBuild) and I have to keep going in and un-ticking it between jobs I am doing, if this were a per type option then I would never have to worry about it again -EDIT- Option 2 would be 2 send to options; Send To / ssEditor (AutoBuild) Send To / ssEditor (AutoBuild .apz/.pgz)
I'm not sure I understand. With the option "Make Archive Deployment Package" enabled ssEditor builds ppGame-folders to .pgz-archives. (And ssApp & ppApp folders become .apz). Do you mean: Send To / ssEditor (AutoBuild) --> Builds with "Make Archive Deployment Package" option off ... will leave everything inside folder. Send To / ssEditor (AutoBuild .apz/.pgz) --> Builds with "Make Archive Deployment Package" option on ... wraps up the folder into an .apz or .pgz archive. If that's the case, then this would make BP happy too. Or is it something else entirely?
Yes that is what I mean, but it would be good to make ssEditor hold the settings separate if you want to get into the guts of your code, else I'd be happy enough with the 2nd send to sooner You can still leave both in as some people do build apps and games from within ssEditor - just not me... or trouba for some cases (like updating existing apps)
Yes, that's actually easy to do as ssEditor accepts switches to override current options/settings: Code: -Autobuild : Tells ssEditor to automatically build based on the current options/settings. Can be overridden with the following (optional) switches: -MakeExpressInstaller=off|on : "On" makes the .apz/pgz archive packages. "Off" forces building of ssWPI type packages instead (folder packages). Like so:
And oh, yeah. That "-autobuild -MakeExpressInstaller=off" is the one that has the bug referred to earlier.
I made a very simple SFX that makes the above two shortcuts for AutoBuilding in the SendTo Menu. I am automating everything about installing my PC, then I'll decide what I want include with the public one. Drat, it doesn't work, it just shows an empty ssEditor.. ah well, I'll try again.. I tried to fix with the ; " -autobuild -MakeExpressInstaller=off " instead of the error I made " autobuild -MakeExpressInstaller=on' " But I guess that bug is it doesn't work yet, we'll need the new SetupS one day
I REMADE a working one: Sorry about that, I copy and pasted from the thread and must have miss selected, then I reversed them so the =on instead of =off.
Those SendTo shortcuts for AutoBuilding seem to be working just fine. It doesn't matter what the the build option "Make Archive Deployment Package (.apz/.pgz)" is actually set to (on or off). The switches do indeed override it -- as intended. I wonder if I had somehow made a similar mistake with the Sendto shortcuts. I'll incorporate them in the next release as it doesn't appear to be a bug after all.
By the way, I finally got a chance the other day to look at those 20.02.13 revisions to SetupS; and I was impressed with your changes. Nicely done. I ended up making that the new base and incorporated my own changes since 17.12.03. They were mostly more tweaks with the OSArch flags for shortcut defs (and some test code trying to track down a non-existant bug with %SystemRoot%). I did get the project build scripts all cleaned up and the kinks worked out -- especially the uploading parts. After all, it had been over two years since they'd been used. And I also updated the "Online Help for ssTek Tools" to align with the most recent edition of the help file from SetupS v17.12.3. I had also nearly forgot that a release earlier that year (v17.3.25) had added quite a few undocumented new features and tools ^: Code: --------------------------------------------- v17.3.25.0 (March 25, 2017) --------------------------------------------- ADD: [SetupS] New components for Windows unattended manipulation: %ClickMe%, %CloseMe%, %SelectMe%, %SendMe%, %WaitForMe% ADD: [ssCore] New Shortcut definitions flag "AssemblyNoWait" to change the default behavor of Process Assembly so that assembly won't wait until a program or an installer finishes running or closes. This affects the new components above as well as %ProcessKill% and %WaitForIt%. ADD: [ssEditor] AutoIt Window Information tool to ssEditor (Ctrl+I). Look for it in the menubar under Tools. Should be really handy for getting those Control-ID triad's for %ClickMe%. ADD: [ssEditor] Windows Task Manager (Ctrl+T) to ssEditor's tool menu. Will be useful for both %ProcessKill% and %WaitForIt%. --------------------------------------------- v17.3.20.0 (March 20, 2017) --------------------------------------------- CHANGE: %WaitForIt% will additionally force SetupS to pause until a specific process is created. Needless to say, I never got around to updating the help-file.
Great to see progress, I am happy to give some time back to SetupS as I use it almost every day, I just didn't know how to use the debug logging before so I never really helped optimize it's function calls to suit the use cases we had considering you never designed SetupS to even work with a WinRE, it's quite impressive it didn't care and worked anyway - so great job from you there.
Thanks. Actually, until recently, I don't think it was ever even tested in those sorts of environments. Hell, I'm still surprised you managed to squeeze some functionality out of it with Linux. Anyway, except for the text find & replace function, I think I've managed to bake-in most of our latest tweaks and fixes; and I'll have a release available shortly. I still need to update the various built-in tools/utilities and the help-file, of course but I'll do those later. Maybe for some sort of 10th Anniversary Edition.
Thanks! Freezer, could you give an example of how the following function could be utilized? EDIT: Some additional features or even fixes I thought about just now for SetupS: - When calculating size in SetupS CPL, do so according to the host OS Arch only. So when installed size is generated, do so only from the _x64 folder when on x64 OS, etc. - Right-click a ss/ppApp.reg file and install them with/via SetupS, meaning the SetupS-specific variables such as %ppApps% get processed. This is probably not feasible but it would be nice - As mentioned before, a function to make an arch-specific version of a dual-arch ppApp for inclusion in arch-specific OS images and AppDiscs.
That just means that you can use any of those three pairs for Shortcut Defs and DualArch apps (in the "Flag" field): #Is_x86# / #Is_x64# Is_x86 / Is_x64 Is_86 / Is_64 Though they'll all resolve to the format of #2 (Is_x86 / Is_x64):
All good suggestions, thanks. That first one though may not be very helpful. For example, say the .app is saved on an x86 arch but then it's viewed on an x64 arch -- it would still show the installed size for the x86 arch. It might be more practical to show both installed sizes; an x64 and an x86 one so you'd see the accurate size for the desired target host OSArch. That may have been what you meant though. The other two I have actually been considering myself. Those SetupS-specific variables can be rather useful at times, can't they? Especially during testing or debugging. And not just the .reg file but also processing the .cmd file would be useful too. And having an automated way to split off arch-specific apps could be convenient. I'd also like to see it applied to some ssApps, as well -- not just dual-arch ppApps.
We may need a separate silent install to add advanced features, I can't imagine many end users needing such features (yet, or ever?) and adding to context menu's isn't a good habit to get in to, I remember back in the LastXP days when I'd add too many items and they would add a down arrow to the bottom of the menu because it goes off screen. Would be nice to be able to do sub menu's in file types but that requires .dll's and they crash explorer and slow it down. so I feel we should make it separate, up to you guys tho.
I think what Trouba meant was using the SendTo sub-context menu with .reg files to the (already existing) SetupS entry. It wouldn't increase the size of the Sendto context-menu; it would just require SetupS to recognize the .reg file-type and then process the .reg file only -- using the info in the .app file. I think that's very doable -- almost trivial IMO and a negligible increase in code-size. I would also like to include .cmd files as a new SetupS recognized file-type. You are right, though. Not many end users would have any need for such a feature; but ssApp/ppApp makers like us might find the new feature very useful.
Ah yes, I see what you guys are saying now, even if a .reg or .cmd doesn't have SetupS commands it'll still work with it too so all good. -EDIT- I'll get to updating ssWPI and it's source code release to have the new SetupS version.
Yes, and since SetupS already has admin privileges, no need to go to the extra effort of having to elevate them either. Also, SetupS treats .cmd slightly different depending on its location: SourcePath versus AppPath.
Freezer, when I put the following in ppApp.cmd in a x64-only ppApp: %Extract% "%AppPath%\_PatchPFx64.7z" -o"%ProgramFiles%" and save the .app file with SetupS, it changes into: %Extract% "%AppPath%\_PatchPFx64.7z" -o"%ppApps%" So this renders the variable substitution non-functional. I know the location change can make sense, but audio apps often save their vst plugins to common/shared locations so that all audio apps can load the plugins (normally: Program Files\VST). It also does this with Glenn's version where he changed the PE stuff so I think it has always been doing that. CommonFiles location does work, but root of ProgramFiles and I imagine ProgramFiles(x86) also don't remain unchanged in the ppApp.cmd file.
I noticed this bug a long time ago, my work around was to make a dummy ppApp.cmd and them make a separate DoIt.cmd, then I had the following code in my ppApp.cmd: @echo off cd /D %~dp0 call %~dp0DoIt.cmd This leaves the .cmd variables or paths in tact. It does mean that %Extract% wont work tho, so might be worth a fix. I don't feel that saving a .app .apz should remake .cmd files, they should be left as the app creator intended.
A better work around would be to embed the path inside the archive. I think 7z will even recognize %Programfiles% -- you'll have to test though. Anyway, output path could be anything. I.e., %SystemDrive% or even "." I'm still curious why a ppApp is looking for stuff in %ProgramFiles% instead of %AppPath% or %ppApps%. If %ProgramFiles% is referenced in the App's ppApp.reg for example, then it'll fix it to the correct one -- which is what you're seeing actually. Huh, deja vu? (from here ^) And what Glenn says: Certain folders like %CommonProgramfiles%, %AppData%, are not affected. But as you pointed out, it'll get wiped at the next OS re-install. Unfortunately, many of our ppApps -- except those converted from PortableApps.com -- are not well behaved.
