Miscellaneous discussion (SetupS)

Ah yes, that is nice That is much better indeed, no extra archives. Earlier I was going to ask you about MkDir because I couldn't get the Copy command to make the necessary folder, and I couldn't create folders, only copy files. So then with my limited coding knowledge I found a way around it and used an archive. But this is what I was looking for!!! Thank you.

These findings answer that whole 'applying patch at regen stage' discussion (for me anyway) I feel like we kept revisiting in the past. Especially those months ago about SetupS; but now it's clear in those discussions about SetupS every one was on a different page than the other person LOL

 

Wow, I had a lot more apps than I thought on which that technique needed to be applied so good thing there's a solution, thanks for the share. It does indeed register/activate the apps both in Install-mode and Regen-mode. I guess the <Script> method is the best way, I don't think this could be integrated into SetupS in any easy way. Sorry, Freezer, sometimes I present you with impossible requests Like you said, <Script> is the real workhorse here and it can always be run whether in Install- or Regen-mode.

 

<Registry> is no slacker either. Pair its use with <Script> and you can pretty much do anything imaginable with SetupS in either Install- or Regen-mode.

As I said earlier, those are all I use to revive a ppApp (re-regged or whatever) after a complete OS reinstall.

 

BTW, did you guys notice when you have the fadertainer set to top-right and run ssWPI and the mini-installer, it off-sets the fadertainer image?

 

nope i did not i have mine set left center

 

Is ssWPI using an old .app for SetupS somehow? One that still lists "Development Setup & Installing" in <Catalog>? Or one that <ShortcutS> somehow have the startmenu paths listed incorrectly?

This is just bizarre. Has anybody been able to recreate this (or again, in Xan's case)?

 

Well, we all know ssEditor has a long ways to go yet. Fortunately ssEditor uses a separate version numbering

"Graphics Icons" is still listed in the Menu Catalog combo. The only time something "disappears" from the combo is when that item is already in the Catalog List. Remove it from the list and you'll see it reappear in the combo.

You're right about the installer list though. It seems the switches box is broken somehow.

 

Off-sets it how? or to where?

Anyway, I know the FaderModules can manipulate the fadertainer images but I didn't know ssWPI would be as well ... ?

 

From what I remember, all ssWPI does is more or less tell SetupS that you want to run the fadertainer. As in most cases, SetupS does all the heavy lifting. Kind of Off Topic, but I didn't have a chance to look at the latest ssWPI this weekend as I planned. My air conditioner attic unit leaked through our ceiling, which had just been painted a month ago, and I had to take the AC apart to get to the leaking pan. (Broken AC in South Carolina in August is kind of an emergency, but with no extra funds, I'm fixing it myself. Never done it before, so learning as I go. Trouba, I know you know how much fun attic work is in this weather.) The pan's at a metal shop today getting a new one made, so we ought to have cool air in the next day or so. Then I'll get to ssWPI. Sorry for the delay.

 

#Directives# only work in <Assembly> (which is where those installers should be anyway)

 

Why is it seeing that app as a ppApp instead of an ssApp?

 

Ah. I didn't know the RunRunAway fadermodule was being used.

LOL, you wrote RunRunAway

 

The reason is because <Script> gets processed by the OS not SetupS. Basically all SetupS does is send a file to the system command processor. Wholesale.

Also, it never occurred to me to do any type of modifying like that on that level beyond the simple %variable% substitutions it already does (which is why the %Components% work with <Script>).

This is in contrast to <Assembly> which SetupS does processes but on a line-by-line basis -- sending each line to the system command processor instead. Also when the #Directives# were being designed, the focus was for Install-mode uses. So again it never occurred to me to attempt to figure out some way to get (at least some of) them to work in <Script>

Another difference: <Script> can pretty much be run stand-alone. <Assembly> could not.

 

why is it running installers and those from %ProgramFiles%?

Doesn't sound like a ppApp to me -- sounds more like you're using Regen-mode to install a de-facto ssApp LOL

 

LOL, whatever you say boss... I'm only pointing out that it seems to me that the path of least resistance would be to simply leave it as an ssApp

Though I did like your method of determining OSArch from a batch file.

 

So there's no way to determine what registry values changed and to use <Registry> instead?

Technically every app can be made into a ppApp -- and I agree about making ppApps wherever possible -- but sometimes (to me anyway) it's just more practical to leave them as ssApps.

 

You are correct that we are substituting %Variables% and %Components% in the .cmd-file SetupS creates before sending it on to the system script-processor. And you are also correct that it would introduce too many problems trying to process a script -- not to mention re-inventing the wheel -- when there is already a perfectly adequate script-processor built-into the OS

One way to think of the difference is to imagine that for each line in <Assembly> you are using "Start, Run" one-line-at -a-time such that each line is independent of any other line...

... whereas for <Script> you are using "Start, Run" with a whole batch-file (for example, "ppApp.cmd") such that any line in the batch-file could be dependent on another line in the same batch-file. "Goto Label" or "Set var" are examples that immediately come to mind.

Regardless, you've got me thinking about if we could possibly incorporate #directives# into <Script> -- damn you! LOL

I'm also thinking the only possibilities are the gate-like ones such as #Is_x64# or #Is_NT6#. The other directives would be nonsense; but the gates could simply "filter" the lines containing off-OS or off-Arch ones from the batch-file SetupS creates before it sends that file off to the system script-processor.

Unfortunately, I think adding such a thing would break the ability to test the <Scripts> as a stand-alone -- at least for the ones using #gates# anyway -- because now it is no longer a standard batch-file and SetupS will be required to "pre-process" such files first.

But sounds like an interesting challenge nevertheless

 

Actually, I do. <Script> and <Registry> I like to copy & paste from the actual tested .cmd or .reg files into ssEditor -- and it will substitute the necessary %variables% to make it truly independent of my system.

But that's just me

 

Well I don't think could put it into the %variable% substituting functions because not only does <Assembly> also use those but so do functions like _AppRead, _AppWrite, etc.

No, I think we'd have to insert such a beast into the ProcessScript() function -- or even ProcessRegistry() function -- as it is the one creating the temp-file that gets processed by the system. Something along these lines:

Code:

$OSArchGate = True
Select
    Case StringInStr($Line, '#Is_x86#')
        $Line = StringStripWS(StringReplace($Line, '#Is_x86#', ''), 3)
        $OSArchGate = Not $OSArch64
    Case StringInStr($Line, '#Is_x64#')
        $Line = StringStripWS(StringReplace($Line, '#Is_x64#', ''), 3)
        $OSArchGate = $OSArch64
EndSelect
$OSVersionGate = True
Select
    Case StringInStr($Line, '#Is_NT5#')
        $Line = StringStripWS(StringReplace($Line, '#Is_NT5#', ''), 3)
        $OSVersionGate = $OS_NT5
    Case StringInStr($Line, '#Is_NT6#')
        $Line = StringStripWS(StringReplace($Line, '#Is_NT6#', ''), 3)
        $OSVersionGate = Not $OS_NT5
EndSelect
If $OSArchGate And $OSVersionGate Then FileWriteLine($File, $Line)

Sometimes I really hate you.

 

Done. Added new magic to SetupS

... or by provoking them

Speaking of (lol), any leads on where to look for Xan's bizarre case of "- Development" ending up as sub-folders to "System Installing" (catalog because it's placing a LastOS sub-folder into a Kazz one)?

That and take care of ssEditor to get it to add items from the Installer/Useage edit boxes and we should be all set for a new release

 

Either the last update (or the one before that), I'd updated the <ShortcutS> to the following:

Code:

<ShortcutS>
    Target="SetupScp.exe"
    Comment="Applet to select an Advanced StartMenu/Sorting Style, ppDrives, etc."
    Name="SetupS Control Panel"

    Target="ssEditor\ssEditor.exe"
    StartIn="ssEditor"
    Name="SetupS Editor"

    Target="Regenerator.exe"
    Arguments=-AllDrives=no
    Comment="Create StartMenu Shortcuts for all your ssApps, ppApps, & ppGames"
    Name="Regenerator\All SetupS-tech Regenerator"

    Target="Regenerator.exe"
    Arguments=-ppApps -AllDrives=no
    Comment="Create StartMenu Shortcuts for all your ppApps"
    Name="Regenerator\ppApps Regenerator"

    Target="Regenerator.exe"
    Arguments=-ppGames -AllDrives=no
    Comment="Create StartMenu Shortcuts for all your ppGames"
    Name="Regenerator\ppGames Regenerator"

    Target="Regenerator.exe"
    Arguments=-ssApps
    Comment="Create StartMenu Shortcuts for all your SetupS/ssApps"
    Name="Regenerator\ssApps Regenerator"

    Target="Regenerator.exe"
    Arguments=-AllDrives=yes
    Comment="Create StartMenu Shortcuts for all your ssApps, ppApps, & ppGames on all your drives"
    Name="Regenerator\All Drives\All SetupS-tech Regenerator (all drives)"

    Target="Regenerator.exe"
    Arguments=-ppApps -AllDrives=yes
    Comment="Create StartMenu Shortcuts for all your ppApps on all your drives"
    Name="Regenerator\All Drives\ppApps Regenerator (all drives)"

    Target="Regenerator.exe"
    Arguments=-ppGames -AllDrives=yes
    Comment="Create StartMenu Shortcuts for all your ppGames on all your drives"
    Name="Regenerator\All Drives\ppGames Regenerator (all drives)"

    Target="SetupScp.exe"
    Arguments=-Kazz
    Comment="Installs and resorts to the Kazz Advanced StartMenu sorting-structure."
    Name="StartMenu Resorting\Kazz"

    Target="SetupScp.exe"
    Arguments=-LastOS
    Comment="Installs and resorts to the LastOS Advanced StartMenu sorting-structure."
    Name="StartMenu Resorting\LastOS"

    Target="SetupScp.exe"
    Arguments=-Resort
    Comment="Resorts to the current StartMenu sorting-structure."
    Name="StartMenu Resorting\Resort"

    Target="SetupScp.exe"
    Arguments=-Standard
    Comment="Installs and resorts to the Standard StartMenu sorting-structure."
    Name="StartMenu Resorting\Standard"

Let me know if your current one (v8.11.8.11) is reflecting these or not. Thanks.

 

It does include it. Look again. SetupS "boot-straps" itself and installs itself as an ssApp