Miscellaneous discussion (SetupS)

Because audio apps have their plugins in a shared location so that other apps can access them as well. So for example in this case Acoustica has internal plugins that only work in its own program, but then it provides .dll versions that are VST plugins that can also be loaded by other programs such as iZotope RX or others. So it is in these cases not just about having the specific app access its plugins, but also making them available in the generally accepted locations for such plugins (which is in Program Files). I still don't understand why SetupS can't be made to extract to the location specified, as it can be seen from this example that the logic that changes the paths is a failed one. Thoughts?

 

Kind of a reverse stance on what you'd said earlier^. But hey...

This "variable substitution substitution"... is actually a feature with SetupS that's been around for quite some time (here^). It was originally intended to facilitate switching between build-types; mainly converting an ssApp into a ppApp (or a ppGame). And once in a while, for me, a ppApp to a ppGame and vise-versa. Only the variables %ProgramFiles%, %ppApps%, and %ppGames% are affected depending on the target build-type: ssApp, ppApp, ppGame, respectively.

Essentially it toggles all the references to the "desired" build-type folder in such places as the %AppPath%, script, reg, shortcut-def's, etc. Here lately, I've even been converting ppApps into "ssApps" -- so I'm really grateful for this feature.

We've known for some time now that many ssApp's are really ppApp's with only the location being different. Some have been really odd. Like root folders or %AppData%. In the past that had presented a challenge to the tools to figure out where the app is actually installed.

Still, I don't think anyone ever anticipated mixing the build-types though.

 

A couple...

What about making it an ssApp instead as Glenn has suggested? There's several apps that actually do better as an ssApp; maybe this is one of them. It doesn't sound like it'll benefit much as a ppApp anyway.

Also, last June, when you had encountered this problem before -- I believe the exact same one actually -- you said that the workaround I had proposed worked:

Is it not working anymore?

As short-term solutions, I think those should work.

Regardless, I suppose the more ideal compromise for the long-term would require a fundamental change to the code -- ssCore, which they all use -- such that only ssEditor converts them but SetupS leaves them alone. In other words, make it an internal (optional) tool exclusive to ssEditor only. The best of both of worlds, I guess.

So I am wondering now... are there that many apps affected by this issue?

-- EDIT --
You know, as I'm thinking about it, I don't really see any downside to that idea. Yet.

How I would go about implementing it is another matter. But I'll see what I can do about making it so for the next revision. That and since it seems somewhat related, including processing .reg & .cmd files with SetupS via it's SendTo sub-context menu.

 

Freezer your ideas are the best options in this case, %SystemRoot%\Program Files\ would be a good way to make ssCore skip modifying the path. It should be optional in ssEditor to not modify the .cmd's/.reg's via a menu item (enabled by default), Trouba and I do notice from time to time that we know what we want the .cmd and .reg to do, then ssCore comes along and says "NO! - It should be like this"

I stand by my "if it isn't saving settings in the portable paths then it's not a ppApp" but as Trouba said in this case it only puts plugins/addons inside the OS, it's still a portable app, but will need you to regenerate it so it re-extracts the folders again (such as Adobe Apps have been doing for years). It would be near impossible to make them a ssApp. We always make sure that you don't end up with a dud ppApp on a fresh OS install if you do use the regeneration methods.

 

Upon further reflection, I think I have an even better idea that'll still allow us to have our cake and eat it too. I'll have to dig deeper; but it should be very doable and a lot easier to implement than the previous idea as well. I don't know why I didn't think of this long before; but as I said I need to take a closer look first.

It's one of those it's been staring us in the face the whole time.

 

I do admit I kind of forgot about the other options to achieve "Program Files" at that time, but I think the discussion about possible solutions is good and hopefully something good will come out of it For now I ended up not implementing installing the general VST plugins and just using the in-progam ones for Acoustica.

 

So, the explorer/icon refresh .exe we made (Glenn and I) that kills explorer.exe, removes icon cache, and explorer settings/cache files, is not part of SetupS, correct? I think it was only added to ssWPI by Glenn upon my request, plus we always add it to Last images (desktop context menu). I was wondering if we ever discussed adding this to SetupS, so that certain apps that require an explorer restart (for context menus or other reasons) might achieve that via SetupS directly. Or maybe there are downsides to that? There is a "Refresh Desktop" option in SetupS but it does not kill explorer and remove the cache files.

It would probably be good to add to the SetupS "Tools" folder and make it an option.

 

It would be useful as a flag option and add it to any apps and also as a command line switch to manually do it so can be called from a batch file seperate to an app install, then you can choose to do it once at the end of ssWPI or after you manually call installs from a batch file at the end of an install. As the 2nd option is more common it would be why we only added it to ssWPI so far.

 

I really think we need to re do the apps and update SetupS and it's editor to have range of supported OS's, instead of individual ones, ssWPI will need to hide items and to do this I'd need to check if it's a supported OS,

My Idea is to update the Filename output to be:

From:
KMSpico.(Activate.Windows.&.Office)_v10.2.0_NT6_ssApp
To:
KMSpico.(Activate.Windows.&.Office)_v10.2.0_Win_7-10_ssApp
OtherApp_v1.0.0_Win_7_ssApp
AnotherOtherApp_v1.0.0_Win_11_ssApp

This would make it that Windows XP will be displayed as Win_6 (not 5.1)???

Or maybe (not my preference):
NotAnotherOtherApp_v1.0.0_Win_XP_8_10_ssApp (Unlikely to ever be XP and not 7 compatible, but show example of including every Supported Windows).


Freezer, I'll have to leave this naming up to you to decide how we could work around existing items, or if I just assume the existing "OS=14 (Vista/7/8/8.1/10)" in .app files will be able to support it and I need to re-do ssWPI to support it.

I'll release ssWPI updated for now, but it ill lack the ability to hide unsupported apps until we decide.

 

I think all(?) of the possible probable 'NT version' = 'MS OS' pairs would be:

5.0 = 2K
5.1 = XP
5.2 = XP 64, 2003, 2003 R2, Home Server
6.0 = Vista, 2008
6.1 = 7, 2008 R2, Home Server 2011
6.2 = 8, 2012
6.3 = 8.1, 2012 R2
10.0 = 10, 2016, 2019, 2022, 11 (or the NT designation is no longer being used as its version.)

Realistically, as to OS that users of ppApps/ssApps most care about, that list can probably be simplified as XP, 7, 8, 10, and 11? Users of 2K, XP 64, Vista, and all of the server versions are rare, and I think app differences between 8 and 8.1 are also rare, but there are some. So, including more OS names to be complete is a good idea.

I agree that it would be very unlikely that an app compatibility would "skip" an OS, so it would seem to be easiest to do some sort of OS range, ie min--max, such as you showed above:

SomeApp_v1.0.0_Win_XP-11_ssApp
OtherApp_v1.0.0_Win_11-11_ssApp
AnotherApp_v1.0.0_Win_7-10_ssApp

Coding-wise, I like the idea of using the NT version number, but apps that are not Win 11 compatible, or Win 11 only, create a problem, so going with the OS "name" seems the best option. Leading the OS names with _Win_ and bracketing the min and max such as _min-max_ should give ssWPI a relatively easy way to identify them, if they are there. If they are not there, I guess ssWPI should assume _Win_XP-11_? You could also indicate "everything up to and including" as _Win_-10_ and "everything starting with and after" as _Win_11-_. If it ends up that using the NT version number does make better sense, then just change _Win_ to _NT_, but you'll have to come up with a way to differentiate Win 10 and Win 11.

 

Oh I don't use the file names in ssWPI to show them or not, I use the OS= inside the .app .ppg files, but for human understanding it makes sense. I did word it all wrong above, sorry for adding to confusion. I'll wait for Freezers SetupS edit (if he's been about?) as every time I build my own SetupS it differs from his XP built versions, so I rather let him control the public version (I have been known to edit it and pass code changes to him before).

 

Yes, that's much how SetupS does it -- by comparing the .app-file's "OS=" setting to the target's NT version. Omitting "OS=" from the app-file or setting "OS=0" will allow any NT version of Windows. That "OS=" setting uses a binary flag to divide the platforms, like so:

0 = None specified or "Any".
1 = NT5: 2000, XP, 2003, etc.
2 = NT6 (pre-Metro/Modern): Vista, 7, 2008, 2011, etc.
4 = Metro/Modern (pre-Win10): 8, 8.1, 2012
8 = NT10: 10, 2016, etc.​

Clearly I'll need to add a "OS=16" for "Windows 11" if such a thing is needed as I think ssWPI might be using this.

Fortunately, there's a much more flexible method already in place to further refine the intended target system by including the following gate directive in the assembly tab (on the same line as the setup/installer .exe/.msi):

#Is_OS<|=|>|<>|<=|>=V[.v[.bbbb]]#
where: V.v.bbbb is the Windows NT version (also Windows NT releases) of the target system. This can be just the Major, the Major.minor, or Major.minor.build.

Note, there are some special gate directives to abbreviate the above a little bit:

• #Is_NT5# : Process this line for NT5.x OS's only. E.g., Windows 2000, XP, Server 2003.
• #Is_NT6# : Process this line for NT6.x OS's only. E.g., Windows Vista, 7, Server 2008, 8, 8.1, Phone 8.
• #Is_Metro#: Process this line for Windows versions using the StartScreen (Metro). E.g., Windows 8, 8.1, Server 2012, Phone 8.

Some examples of the OS gate directive:

• #Is_OS=5.1# : Windows XP
• #Is_OS=5.2# #Is_x64# : Windows XP Professional x64 Edition
• #Is_OS=5# : Same as #Is_NT5#
• #Is_NT6# #Is_OS<6.2#: Windows Vista & 7 (also Server 2008); equivalent to #Is_OS>=6.0# #Is_OS<=6.1#
• #Is_x86# #Is_NT6# : The x86 editions of Vista/7/8
• #Is_OS>=6.2# #Is_OS<=6.3#: Same as #Is_Metro#

​

Okay, so here's a quick breakdown of those NT versions/builds used by Microsoft:

5.0.2196 Windows 2000
5.1.2600 Windows XP
5.2.3790 "Windows 2003", x86 & x64

6.0.6000 Windows Vista RTM
6.0.6001 Windows Vista SP1
6.0.6002 Windows Vista SP2
6.0.6003 Windows Vista SP2 Update

6.1.7600 Windows 7 RTM
6.1.7601 Windows 7 SP1

6.2.9200 Windows 8

6.3.9600 Windows 8.1, "Windows 9"

10.0.10240 Windows 10 version RTM/1507
10.0.10586 Windows 10 version 1511
10.0.14393 Windows 10 version 1607
10.0.15063 Windows 10 version 1703
10.0.16299 Windows 10 version 1709
10.0.17134 Windows 10 version 1803
10.0.17763 Windows 10 version 1809
10.0.18362 Windows 10 version 19H1
10.0.18363 Windows 10 version 19H2
10.0.19041 Windows 10 version 20H1
10.0.19042 Windows 10 version 20H2
10.0.19043 Windows 10 version 21H1
10.0.19044 Windows 10 version 21H2

10.0.22000 Windows 11 version 21H2
​

(Curiously, the early preview builds of Windows 10 had the version number NT 6.4)

Unfortunately, Microsoft has muddied the waters further by leaving Windows 11 NT Major.minor at "10.0" and differentiating it by only the build number "22000". Even more confusingly, Windows 11 build 22000 has the same version name as Windows 10 build 19044... namely "21H2".

So basically to target only Windows 11+ we can use this: #Is_OS>=10.0.22000#

 

So -- #Is_OS>=6.1# #Is_OS<10.0.22000# -- would indicate the app applies only to Win7 - Win10, ie not Vista and earlier and not Win11 and later, correct?

It looks like SetupS is already able to handle things correctly.

But I thought that part of Glenn's original comments:

and

were more about enhancing the Filename so that it would be obvious to the user, looking in the repo, which OS the apps were meant for, without requiring them to download the app, open the app, and look in the .app or .ppg file to see if it applies to his OS or not. Right now, there are very, very few apps where this is required, but it looks like that is likely to change, and for conformity, and to get folks use to the concept, it might be nice to clean up the existing apps.

 

Here:

But you're right, the gate directives for OS-Arch merely filter the apps/games at the install point. For ssWPI (and ssGooey, I should've added), automatically hide the non-compatible OS-Arches dependent on the tags in the app-file so the install isn't even presented. That's why the filenames can be pretty much anything. This (re-)naming will of course have to be done manually as there's only so much ssEditor can do automatically. There are times I end up adjusting the filenames post-build regardless, mainly to clarify something about the package.

By the way, this is how I have mine set:

​

FYI, this is the file-naming convention ssEditor has been using. But even I don't exactly adhere to them when I rename my builds.

​

Unfortunately, I'm so far behind on things... I wasn't even aware if there were apps (or games) being released exclusive to Windows 11.

So @Glenn, go ahead and start using "OS=16" for Windows 11 since that's what it'll be once I update the SetupS File Specification (.app/.ppg). Just for now you'll have to manually add it to the .app-file until I can update ssEditor to follow suit.

And so much for "Windows 10" being the final major version. (Although it appears Windows 11 version is still "10.0"... so maybe?)

 

Here's a small kludge I made to find out the NT version number on any given system.

So when I ran it on Windows 10 version 1809, I was surprised to see a fourth number included (right after the build number). I've no clue what that 4th number represents and whether or not it'll cause any problems with SetupS. (But I think if there is, it'll just be with the gate directive #Is_OS#)

​

And yes, FYI, Windows 10 (and now Windows 11) are still considered versions of the Windows NT operating system.

 

I guess it's possible that it's a ssWPI issue, or that something else is going on. I've had some weirdness occasionally, like SetupS sorting totally botching up (maybe some kind of file corruption or something). Not that long ago I had it when installing 7+ Taskbar (just by double-clicking the ppApp.app file) that it started a start menu sorting routine (kind of sounds like what you're having there) but then it went away or I reinstalled, can't remember. So yeah, here and there some inexplicable stuff happens But normally this is very rare.

If it is specific to the ssApp, it may serve to look into the various designations there, like:

AppPath=%ProgramFiles%\VMware Workstation <-- the path may have changed since the v14 ssApp that I borrowed the .app file from


Start menu sorting configuration should be fine, it should just place a shortcut to VMWare in the root of the - System folder (when using LastOS sorting): StartMenuLegacySecondary=4 System -- or else, when regular/standard sorting is applied, it should just show up in unsorted start menu as a folder.

^^ However, no specific shortcut for VMWare Workstation is indicated in the .app file, so it would be up to SetupS to figure that out. Since KeepInFolder was used, it should save the program, help file, uninstall shortcuts in a start menu folder. ^^


For Flags, this is important to have set (as in the .app file) : Flags=KeepInFolder|KeepAll|NotMetroFriendly -- where the "NotMetroFriendly" is normally used for apps with multiple shortcuts, as on Win8 and above this is required


Other than that, I can't see what in the ssApp (.app file) could cause such issues.


By the way, this is where I got the unattended instructions and it does pertain to v16 of VMWare Workstation, so it should work for unattended installs: https://docs.vmware.com/en/VMware-W...UID-F3F1A8B9-D298-4461-BEAB-185CE3E158ED.html

 

LOL, I was posting that link to you THE VERY SECOND you posted yours. Yep, that's the instructions I used to populate the .app file

 

The quotation marks!? They are there in the first example, but missing in the second. I had them included, as per the first example (I did not include custom install dir switches). Are you saying the quotation marks should not be there after all? This is making me want to install a VM lol