Miscellaneous discussion (SetupS)

If you're going to do that, you could have it check the first line of AutoInstall_Arch.ini for the keyword Kazz or LastOS and set it appropriately, then delete the line. If they are not there then just carry on using the default. Just a thought. But you're probably right. I'm not sure anyone choosing to use AutoInstall will want the default, and I don't know anyone who uses Kazz regularly.

EDIT: Or I guess it could look for the trigger file in the same place that AutoInstall.ini is located. If found, it can set the menu style appropriately, by copying it to the System Drive? You could even modify the code that is in ssWPI.Main.StartButton.Action, under the - 'Add Menu Sorting Methods - section to do the copying for you. That way you wouldn't have to edit AutoInstall.ini.

EDIT2: Actually, the more I look at it, whatever method you use to tell that you want to set the menu sorting a certain way, all you have to do in ssWPI is set the variable "MenuSort" to either "Kazz" or LastOS or "Default" and the code in ssWPI.Main.StartButton.Action, under the - 'Add Menu Sorting Methods - section will set everything up to trigger SetupS to do the appropriate sort, UNCHANGED. Just set "MenuSort" -- And set "ManualSetMenu" to "True" if you want to make sure everything is resorted including existing apps, which I guess you do. LOL I don't know why I'm telling you this, RON. Remember our very heated arguments about just this subject as I was trying to get it through my very thick head how this all works? You know WAY more than I could pretend to know about it, LOL Carry on - just ignore me. lmao

 

Intentional. Here's why: the source code and developers' packs were getting much too large so instead I have "ssEditor.chm" get recompiled from its source file "ssEditor.hnd"

This also means you'll need to install these two ppApps -- and it also means you'll need to compile on the same drive as your ppApps:

• Microsoft.HTML.Help.Workshop_v1.32_ppApp.apz
• HelpNDoc_v2.9.0.144_ppApp.apz

Anyway, this saves a whopping 4 MB for each of those archives

 

ok freeze i know u mean well but u lost me lol and yes its easy todo lol

 

Check your updates

New SetupS Sendto Suite update -- v8.11.8.8 (Skynet!) -- see first post for the goodies. Recent Change-log:

Code:

------------------------------------------
v8.11.8.8 (August 8, 2011) Skynet
------------------------------------------
ADD: Autocomplete for <AppPath>. In addition to shortcut searching, SetupS also uses the Uninstall section of the
     Registry to determine where the App is actually installed. Failing all these, if it cannot determine the
     actual install folder then it will attempt to derive one from the other information in the .app-file.
ADD: Autocomplete for <StartMenuSourcePath> -- not very refined at this time.
ADD: GPL licensing information/notification for the SetupS Control Panel and ssEditor.
CHANGE: "Safe Install" enabled by default.

This "Skynet version" will either give us a more robust SetupS -- or a more unstable, app-breaking one! LOL But despite the "in-joke" nickname, there are some fundamental differences between this Skynet and the previous one. There'll be a later posting detailing what they are.

 

That sounds like some tricky stuff you've added. So is it fair to say we have come down from Final stages and are now back into the developer's builds again?

Actually, it sounds like you are trying to do that stuff we didn't like before

 

Depends, if you're using one of the troublesome apps for example -- otherwise it's business as usual.

Well the idea(s) are still sound, I believe; but the difference from before with the unpopular version was that I went both too far in one area (assuming the root path) and not far enough in another (auto-completing the AppPath).

 

OK, just making sure. Everything working so nicely at the Transcendental level

 

Check your updates

New SetupS Sendto Suite update -- v8.11.8.11 (Balanced!) -- see first post for the goodies. Recent Change-log:

Code:

------------------------------------------
v8.11.8.11 (August 11, 2011) Balanced
------------------------------------------
FIX: Autocomplete for <AppPath> to remove invalid path characters from <Title>.
FIX: Read-only, Hidden, or System folder & file attributes for %LastOSResources% are cleared during write operations.
FIX: Autocompletes for <AppPath> & <StartMenuSourcePath> are only done during install-time to speed up such
     processes as Regenerator or Startmenu resorting.

I know there's been some chatter about changing the out-of-the-box settings for SetupS to "Tray-only" and with Fadertainer enabled and set to the top-right corner.

Normally I'd agree -- for I've got mine set to "Tray-only" -- but I do not think this would be in the best interests of any first-time users. I've put a lot of thought into this issue ever since I first introduced those reporting/notification settings (back with v8.10.6.0, I believe) and I came to the conclusion that such new users should not be "scared" off by a stealthily seeming SetupS. So they should opt-out of "Show everything".

As for Fadertainer -- which was introduced only rather recently so granted there's not been that much time and thought has been put into it -- yes, this would seem like a flashy, eye-candy showcase item for SetupS but the Fadertainer has a couple issues that we should consider regarding first-time users:

1. It slows the installs down.
2. Doesn't always work on some systems (OS's, VM's, or old graphics cards, etc.)

These sorts of downsides give the impression of something being buggy or broke and I wouldn't want these first-time users to be put off by these issues so instead they should opt-in to Fadertainer "at their own risk"

Of course, all these settings are over-ridden by any switches sent (via other utilities using it such as Regenerator, or ssWPI); plus, we have the "retention" of these settings across SetupS update-installs and now using Trouba's clever method even across OS re-installs (but the read-only issue should still should be fully tested).

 

Thanks, Freezer. Theoretically, how does this SetupS version deal with any 'vagrant' apps (ones I install in Users folders, etc.)?

Also (maybe more a question for RON), how does the SetupS online update feature affect us updating the SetupS files in the LivePE/00WinBuilder? Just asking in case someone uses wired LAN card and has internet access in LivePE.

 

Autocomplete, you mean? If so, then the only time that kicks into gear is when <AppPath> is empty or missing or has only one of the following listed:

• %ProgramFiles%
• %ProgramFiles(x86)%
• %CommonProgramfiles%
• %CommonProgramfiles(x86)%
• %SystemRoot%
• %SystemRoot%\System32
• %SystemRoot%\SYSWOW64
• %SystemDrive%
• %ppApps%
• %ppGames%

Notice they are mainly the roots of typical system folders (or critical SetupS ones). And if <AppPath> contains one of those by themselves then SetupS considers it an incomplete <AppPath>.

For example, if we have a source .app-file like this:

-----------------------------------------​

<Title>​

CCleaner​

[...]​

<AppPath>​

%ppApps%​

-----------------------------------------​

Then expect SetupS to "complete" the install-path .app-file:

-----------------------------------------​

<AppPath>​

%ppApps%\CCleaner​

-----------------------------------------​

So basically to prevent yours from being classified as a "wayward" app, simply make sure you have a completed <AppPath>.

 

OK thanks. Yes I knew it wasn't going to be permanent, I was just wondering if we should expect instability or errors when people would try to use the update feature (I never would, but just curious).

As for the app path changing, that is what I was (sorta) afraid of, it means that (pp)apps that need to have certain files present in certain directories and look for files there won't work the way I used to make them. But that is no problem at all, in fact, it would be better to install them to the ppApps folder and use the extract command in the .app files to write such files to the directories they need to be in (usually in Users subfolders). I just circumvented doing that for a while because since SetupS cannot reapply patches once a ppApp is installed using regenerator, and someone would reinstall their PC, the license files won't install anymore and the app becomes unregged. So I previously thought it would be better for the app to just disappear than to remain in a non-system-drive ppApps folders and get regenerated again (unregged).

But since I personally put ppApps on the sytem drive this doesn't even apply, so I'll just start using the extract/patch feature and actually install the apps to the ppApps folder.

 

Ah, from what you're saying Freezer it would seem the wayward app scenario is still possible... And I assume SetupS still accepts %AppDataCommon% and such variables so it should be OK?

 

You can still have <AppPath> = "C:\Document & Settings\{Username}" or whatever you want. SetupS sees it as a completed <AppPath> and therefore will leave it alone. In fact, it will copy the app's SetupS-aux files there as well.

 

OK, thanks Freezer, that is what I hoped you were saying

RON: no, I meant any included Patch archives that install to locations other than the app destination. So in the case where I include a patch archive that is meant to extract to a User folder (because that's where that app looks for it's regging/activation info/files) -- in the case of regenerator that patch will not extract to that location again, it will only do so when the ppApp is actually a ppAppsInstalls.

 

Yes, exactly. What we are trying to do is:

1. Avoid dumping SetupS-related files to certain system root folders (and SetupS ones as well). Having them there aborts certain operations such as Startmenu resorting or Regenerating Shortcuts. For example. say you have those files in the root of your "D:\ppApps" then it stops ppApp shortcuts from getting regenerated or even that your ppApps will not get sorted to a different Startmenu.
2. Have a path that ssWPI can find and therefore determine if the app is installed.

 

OK, very good.

BTW: regarding my former post, in case someone thought so I wasn't trying to get into the whole regeneration issue again, I am aware of the limitations there and accept them, I was just trying to explain why I had previously written the entire app to a needed location in the Users folders (or ProgramData folders) because that was a way to prevent regenerator to try to install it in the scenario of a new OS install (meaning, that ppApp wouldn't exist in any ppApps folder after OS re-install).

 

Yes, this is true about the patch folder/archives during a regen but the <Script> and <Registry> (or their .cmd/.reg counterparts) still get processed. This is how I "re-patch" my ppApps

 

Yeah, I know it's not proper, even I feel strange about such apps LOL

So are you saying you're having the <Script> section extract the Patch when SetupS/regenerator cannot do this through <Assembly>? Kind of like a double-up if you will?

 

Don't forget that once an exe gets "patched" it remains that way forever in its ppApp folder. It may need re-regged later after an OS reinstall (using <Registry>, for example); but the file remains "patched".

I guess I should've said instead, "This is how I 're-regged' my ppApps"

 

@Trouba:

Put your mind at ease (and ours) by experimenting on some ppApps to see if things still work as you expected them to.

And maybe post your findings. Things seem to be getting very muddled even for me.

 

Oh OK, yes I know all that, I thought you were talking about something else (re-applying patch archives somehow). No problem, I'm going to do some tests now.

It was just that everything seemed to finally be stable and fall into place around the time of Transcendental (plus it didn't require changes to ssWPI, etc.) so I felt reluctant to update my Preset stuff but at the same time I'm making some ISO's so felt like I needed to consider it.

 

FYI, one of the reasons I made the %Components% accessible from <Script> was because they were not operable from <Assembly> during Regen-mode.

(BTW, only the #Directives# inside <Assembly> still work outside Install-mode)

 

Everything appears to be working fine so far (not talking about re-applying of patches during regen mode now, I just saw your post when I posted mine lol)