I'll see what I can do about OS gates. Unfortunately, the code for all that is complicated because it's scattered throughout SetupS; plus, AutoIt gives us no easy way to "compare" the OS's by version numbers -- instead it ID's the OS's by name rather than by number.
For me it would unless Glenn knows something that could only apply to Win8.1 over 8.0 (and whether or not that would be important enough). After 8.1 it should be Win9 so I think that should suffice, yes.
Just to be prepared for any future necessity, I like the idea better of converting the OS version to a number as Glenn suggested, especially if tests could then be made for "is OSver>xx". But if that is not possible, as long as the "Is_Win8" gate really means "is OSver >= Win8.0", (including the appropriate server versions?), then that seems to meet the current needs.
Technically speaking the #Is_Win8# gate will be directly tied to the MetroPresent flag. And I'm guessing that Windows 9 will have the same security issues and concerns that necessitated the extra gate -- I'm also presuming that Windows 9 will still be using Metro StartScreen. Bottom-line is that I'm hoping to avoid having SetupS parse overly complex expressions with gate directives -- and the bugs that will inevitably create -- as I think SetupS is nearly 100% bug free right now. Though currently there is no solution for SetupS to handle a condition, for example, of Vista/7 only (excludes XP & Windows 8). And even if SetupS could parse such complex structures, it would have to filter a "double-gate" such as #OS>=6# #OS<6.2# (or something crazy like that).
Thanks for the update, Freezer. Could you give us some examples of those gates? For example, if I wanted something to apply to Win 8.0 and 8.1, but not to Win7 or lower, how would I do that? Also, I take it those gates apply to .reg and .cmd files, as well as .app files, correct?
It's interesting that you ask. I was just getting ready to update the help-file with the new info. Yes. Just like the other gate directives, they may also be used in the following: Script-files (.cmd/.bat), Registry-files(.reg), and in the .app-file under the keys "FileTypes", "RegisterDLLs", "InstallFonts", and the ShortcutS definitions. Note, with ShortcutS definitions, placement of the gate(s) is via the "Flags" key (with or without "#" delimiters). The syntax is very basic and crude as follows: #Is_OS<|=|>|<>|<=|>=V[.v[.bbbb]]# with: < : "less than" = : "equal to" > : "greater than" <> : "not equal to" >< : "not equal to" <= : "less than or equal to" >= : "greater than or equal to" =< : "equal to or less than" => : "equal to or greater than" V.v.bbbb : The Windows NT version. This can be just the Major, the Major.minor, or Major.minor.build. Also new with this latest release is two or more gates used together will have a logical "AND" effect. This will allow one to specify OS ranges and OSArch combinations. Some examples: #Is_OS=5# : Same as #Is_NT5# #Is_OS=5.1# : Windows XP #Is_OS=5.2##Is_x64# : Windows XP Professional x64 Edition #Is_NT6##Is_OS<6.2# : Windows Vista & 7 (also Server 2008) #Is_x86##Is_NT6# : The x86 editions of Vista/7/8 #Is_OS>=6.2# : Same as #Is_Metro#. E.g., Windows with StartScreen (Metro) -- Windows 8 and 8.1 also Server 2012 (even Phone 8 but I can't imagine SetupS on that).
That looks wonderful Freezer! I suppose that the gate directives like #Is_Metro#, while it will still be supported for "older" apps, no longer needs to be included in the help file to sort of quietly deprecate its use. Or can you envision a situation where it would still be necessary or useful? And how does this play into the use of the ssEditor shortcuts "StartScreen-friendly" or "Metro-friendly"? I'm not clear on that.
Thanks BP. Regarding #Is_Metro#, that's a new gate added with the recent release. As I commented earlier, I don't think the StartScreen is simply going to go away with future versions of Windows (unfortunately) but makes for a convenient identifier for such that will have the same issues and problems that presented themselves beginning with Windows 8. But SetupS doesn't really "detect" the presence of Metro either. It simply looks for WinNT versions 6.2 or greater. In other words, think of it as a shortcut for the more cumbersome #Is_OS>=6.2# But with #Is_NT5# and #Is_NT6#, it's unlikely they'll ever be depreciated in the near future for pretty much the same reasons. It's a shame Microsoft didn't just simply bump up the major to NT 7 for Widows 8 et. al. As far as "StartScreen-friendly" versus "Metro-friendly" for ssEditor Shortcut options... It's really unrelated to the gate additions. It's just an exterior change (really only to the GUI) to reflect the fact Microsoft doesn't refer to it as "Metro" anymore and hasn't for quite some time. Internally to SetupS, it'll still be referenced as "Metro" because it's convenient (and easier to spot). Microsoft's over-reliance on the use of "Start" -- Startmenu, Startup, Startbutton, and now Startscreen -- can make one go bug-eyed after a while. LOL
I think I've successfully updated 3 apps with OS gates applied I really like this feature and it will certainly come in handy.
will this addon need to be update , i know setups has had along of changes not sure if it affects this or not ssGenerator_(Requires_ssWPI_Addon) Code: @echo off rem ** Make ssGenerator occur ** REG ADD HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce /V 1FindppDrives /D "%~d0\sources\$ssWPI\Tools\ssControlPanel.exe -ppDrivesScan=Forwards" /f REG ADD HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce /V 2GenerateppItems /D "%~d0\sources\$ssWPI\Tools\ssControlPanel.exe -ppDrivesRegen" /f
Should be okay. Those switches are still valid for ssControlPanel -- which is what it's really using.
freezer i seem to be having a small problem with processkill in setups path to exe is C:\Program Files (x86)\Evernote\Evernote\Evernote.exe what ive always used before was %ProcessKill%Evernote.exe ive also used %ProcessKill%Evernote\Evernote.exe is this one of those times i need to use the full path %ProcessKill%Program Files (x86)\Evernote\Evernote\Evernote.exe
ProcessKill references the "Image Name" as they are listed in Task Manager. In other words, don't specify the path. Also, because the %Components% are basically CLI commands, they need to be first on the line and there needs to be a space between the %Component% and its arguments. This differs from #Directives# which can be placed anywhere on the line. Bottom-line, to fix your problem: %ProcessKill% Evernote.exe Note, ProcessKill doesn't discriminate. It will end all PID's using that "name".
so because i didnt have a space between %ProcessKill%Evernote.exe setups wasnt reading it . i will remember that lol. . right after i had posted this i noticed someone more then likely trouba ,had already upped an older verison of everote as a ppApp . i just updated that one with the new one .
Ok this one works. for some reason the regenerator hangs on "paste as file" but when i deleted that app it ran to completion. another question. how does one regenerate the (im guessing) lastos start menu subdirectory structure for all the default microsoft os tools? the were all there after i installed the os and setupS the first time, but one of the runs of the bad setupS seems to have erased them....both the ms dir...accessories, games, system tools, etc., and the lastos buckets in which some were moved? maybe that could be an option in a new version? to stick all the basic MS tools into the lastos structure, either mixed in with the lastos appz by type or separated out under a special MS folder by type (or both)? thanks, justhangin
SetupS Control Panel (ssControlPanel) does that for you when you select an advanced StartMenu -- even if you select a pre-existing one, it'll do a resort for you and recreate any missing (ssTek) shortcuts including the default Microsoft ones. You could also use one of the provided shortcuts in the submenu folder "StartMenu Resorting". Most of the original "Accessories" are scattered throughout the Startmenu but you can find the majority of the original "System Tools" under "- System/- Windows Tools" (w/ LastOS Startmenu style).
For those interested in what I've been up to lately in regards to SetupS... finally got around to implementing that "ssUninstaller" idea/feature for ssTek apps (and games) that I'd had left undeveloped for quite some time. I've still quite a bit of testing to do on my end; but so far, it's proving to be very promising. FYI, I've left the global option for the new feature to be disabled by default -- one must opt-in to the feature with ssControlPanel -- but can also be disabled on a per app basis as well (which it doesn't default to, of course). Some screenshots... Global option (ssUninstall): Disable option per app/game (ssUninstall):
So it looks like you will be able to: 1) Uninstall all 2) Uninstall all but disable per app 3) Disable Uninstall all (Default) 4) Disable Uninstall all but enable per app (???????) I like Glenn's suggestion to allow the SetupS files to be removed, because that can be an annoyance. For ppApps, there might need to be a couple of options regarding being uninstalled. If they are copied to C:\ and installed there, then uninstall should probably actually remove them from C:\, right? But if they exist on a different drive, then I would think that "uninstalling" them should just remove links to them and any other cleanup required, but leave them where they are so that they can be reinstalled.
Yep. Trouba was who I was thinking about when I said C:\. As to the ppApps, I was not thinking about ppApps on a portable device. Maybe I'm different, (no argument from me), but I store my current ppApps on G:\ppApps\, regardless of whether they are "installed" or not. I don't use x:\ppAppsInstalls\. [ I do keep an archive of all old and current ppApps on a different drive so I can recover if the G:\ppApps\ folder gets corrupted. ] So anyway, if I uninstall a ppApp that is in G:\ppApps\ I don't want that deleted, I would just want the links etc removed.
Yes, Glenn's guessed correctly. It's being intercepted at the registry level so that any external uninstall software -- such as CCleaner or the Add/Remove CP applet -- will automatically envoke ssCleaner functions after an app has been uninstalled. This feature turned out to be remarkably simpler to implement than I had originally imagined; and didn't take much modification at all since most of the structures needed were already in place. The only real difficulty was to get the new function to work on SetupS itself. @BP, the global option just means whether or not the registry will be modified if the uninstall info exists (or is discovered during an install). There will be no ability to uninstall all ssTek apps/games -- I don't really see a need for that. The uninstalls will still have to be done individually, one-at-a-time, just as normal. And in fact, without the ssUninstall option enabled, the entire SetupS suite will be identical to v14.2.0.0
