SetupS File Specification (Discussion)

[bphlpt]

For the entries such as <AppPath>, <StartMenuSourcePath>, etc is this just a "confirmation" of what the installer would do anyway or can it over-ride the installer somehow? ie if the installer' values and the values in these entries are different, then what happens?

Where are the files Category.txt, MenuCatalog.txt, and StartMenuDestinations.txt?

For ssApps, the section <ShortcutS> ONLY applies to EXTRA shortcuts. The shortcuts created during the normal installer execution are controlled/modified using the <Flags>/<ShortCutNamesKeep> sections and for those you really can only indicate to keep them or not. To modify/move them you really need to supress them via <Flags> then create new ones with <ShortcutS>. Do I understand correctly?

Cheers and Regards

[The Freezer]

Where are the files Category.txt, MenuCatalog.txt, and StartMenuDestinations.txt?

Oops, sorry. Right here:

Package Category: viewtopic.php?f=29&t=85#p1135
Startmenu Catalog: viewtopic.php?f=29&t=84#p1134
StartMenuDestinations: "StartMenuDestinations_Kazz.txt" and "StartMenuDestinations_LastXP.txt"

Also updated first post to reflect these.

[The Freezer]

For the entries such as <AppPath>, <StartMenuSourcePath>, etc is this just a "confirmation" of what the installer would do anyway or can it over-ride the installer somehow? ie if the installer' values and the values in these entries are different, then what happens?

In the case of <StartMenuSourcePath> there is no choice, it is required to be supplied beforehand. As of yet, SetupS has no way to determine where the installer placed the shortcuts. If <AppPath> is not supplied or is invalid, then SetupS DOES have the ability to seek out that path but it does that by looking at the shortcuts in <StartMenuSourcePath>

For ssApps, the section <ShortcutS> ONLY applies to EXTRA shortcuts. The shortcuts created during the normal installer execution are controlled/modified using the <Flags>/<ShortCutNamesKeep> sections and for those you really can only indicate to keep them or not. To modify/move them you really need to supress them via <Flags> then create new ones with <ShortcutS>. Do I understand correctly?

Mostly I think you do.

But I feel I should add some clarification here.

Yes, you should use <ShortcutS> for ssApp's to create any extra shortcuts not created by the Installer/Setup but it's not limited to this task ONLY.

See, even though <ShortcutS> is not required for the ssApp's initial install, SetupS does create this section for the .app file inside the <AppPath> folder. This file and the ones for ppApps & ppGames are FULL shortcut defs for ALL the shortcuts. BTW, this file is how the Shortcuts.Generator gets it's info (for all apps and games installed by SetupS)

And this <ShortcutS> section (in fact the entire .app-file) can be copied back to your install-source. Now, you have up-front all the shortcuts that will be created. This would be handy if you wanted to modify these shortcuts to your liking.

<ShortCutNamesKeep> is a list of those shortcuts one wants to keep when the <Flag> KeepAll = off. And the very first shortcut in this list is a special "keep" for those shortcuts destined for the Desktop, Startup, Sendto, or Quicklaunch. BTW, this section also works with ppApps/ppGames too.

Now, of course the <ShortcutS> section is required for ppApps and ppGames since there is no installer to create their shortcuts. This is where SetupS comes in to create them. Also, for ppApps/ppGames, if the <ShortCutNamesKeep> is empty then the very first shortcut in this list serves the same purpose as in the <ShortCutNamesKeep> section... that is for creating shortcut(s) for the Desktop/Startup/Sendto/Quicklaunch.

As an added note here, an alternate tag for the <ShortcutS> section is <ppApps>. Though kind of ambiguous for ppApp shortcuts -- and makes no sense for ssApps or ppGames -- it was a legacy tag that hasn't quite been depreciated yet.

So bottom-line, by coordinating the information between these two sections (<ShortCutNamesKeep> and a Full/complete <ShortcutS>) then you create extra layers of flexiblity to the ssTEK previously unheard of

[bphlpt]

See, even though <ShortcutS> is not required for the ssApp's initial install, SetupS does create this section for the .app file inside the <AppPath> folder. This file and the ones for ppApps & ppGames are FULL shortcut defs for ALL the shortcuts. BTW, this file is how the Shortcuts.Generator gets it's info (for all apps and games installed by SetupS)

lol And I used to think that all the ssApp/SetupS files in the <AppPath> folder were "left over" by a sloppy install routine. Speaking of which, I remember way back when I first tried one of crabdance's early builds which used SetupS, when you uninstalled any app that SetupS had installed, those ssApp/SetupS files were orphaned. Has that been "fixed", if it even CAN be, or is the cleanup routine required and in fact is that why it was created?

Cheers and Regards

PS - I LIKE the enhanced edit box!

[The Freezer]

lol And I used to think that all the ssApp/SetupS files in the <AppPath> folder were "left over" by a sloppy install routine. Speaking of which, I remember way back when I first tried one of crabdance's early builds which used SetupS, when you uninstalled any app that SetupS had installed, those ssApp/SetupS files were orphaned. Has that been "fixed", if it even CAN be, or is the cleanup routine required and in fact is that why it was created?

I like your choice of word: orphaned. I'll use that from now on

Anyway, If you're referring to SuperLLClean, then yes, originally it merely cleaned up the orphaned shortcuts from advanced startmenus -- remember, SetupS moves those from where the installer originally placed them so now the uninstaller cannot find them. Later, for much the same reasons, it would clean up the post-uninstall now-orphaned SetupS-related remnants.

Now if only we can just figure out some way to get SuperLLClean to deal with the SetupS-related registry remnants as well and we'd be all set!

This uninstalling issue is probably the only Achilles-heal for ssTEK. I suppose some might argue that since RON had gotten LastOS down to a science and were so quick and painless to install that you were encouraged to routinely R&R your computer quite frequently. In fact, RON even maintains that for example he never runs a registry cleaner because he just wipes his system drive clean and starts over with a fresh OS

[bphlpt]

Now if only we can just figure out some way to get SuperLLClean to deal with the SetupS-related registry remnants as well and we'd be all set! ... I suppose some might argue that since RON had gotten LastOS down to a science and were so quick and painless to install that you were encouraged to routinely R&R your computer quite frequently. In fact, RON even maintains that for example he never runs a registry cleaner because he just wipes his system drive clean and starts over with a fresh OS

OK, I got the gist of the meaning of R&R, but the actual words the acronym stands for, hmmm - from Wikipedia - "Rest and Recuperation", "Roles and Responsibility", "Resettlement and Rehabilitation", "Rescue and Resuscitation" - The last one seems the closest. lol Though "Ravage and Raze" might be even more accurate.

Back to the point, since SetupS obviously knows what it is moving/creating, whether it is a file or a registry entry, can't it create it's own uninstaller for each app and add a link in the start menu for it? It could remove the "extra stuff" and act as a bootstrap for the normal uninstall routine. I'm thinking it's kind of like DirectX. Microsoft provides no way to uninstall it, and I've even read that it COULDN'T be uninstalled, but that just seemed wrong to me. So as my DXCB builder routine builds the installer, it builds an uninstaller script in parallel. It works. It will uninstall DirectX from any system, not just the one the installer was used on. It causes no errors, registry cleaners find no other "left-overs" after it is run, and DirectX can then be reinstalled with no problem. And as an extra little "fun" thing, the uninstall script is written as a combination .cmd and .reg file all in a single file. I thought that was such a cool little thing and it has kind of irked me that no one else has ever even noticed or commented on it. Ah the disappointments the software writer must endure, oh well. I guess the uninstall routine could be utilized by SuperLLclean (which stands for what?), or as a stand alone thing. I'm not sure which makes the most sense. Anyway, just a thought.

As to starting over on a frequent basis, though admittedly the users of ssWPI are among the most likely to think that is a good idea, until the vast majority of apps one uses are portable it seems it will still be easier to clean up a bit rather than reinstall. At least until we can convince more people to use the LastOS7 type of builds.

Cheers and Regards

[The Freezer]

[...] of the meaning of R&R, but the actual words the acronym stands for [...]

Sorry about that... in IT we call that "Remove & Reinstall"

[...] can't [SetupS] create it's own uninstaller for each app and add a link in the start menu for it? It could remove the "extra stuff" and act as a bootstrap for the normal uninstall routine. [...] I guess the uninstall routine could be utilized by SuperLLclean (which stands for what?), or as a stand alone thing. I'm not sure which makes the most sense. Anyway, just a thought.

Actually I've tossed these ideas around as a possible future feature of SetupS a short while back. I even suggested adding a new section to the spec called <Uninstall> which would function in nearly exactly the same way as does the <Install> one. But it was only ever in a brainstorming stage and nothing became of it. Though RON is seriously considering something along these lines for his new SetupS2 draft especially with regards to the registry stuff.

SuperLLClean is something I wrote inspired by the original "Link Luster Clean" by AnneAadrvark because the original lacked certain features I wanted. So hence, the name.

[bphlpt]

Another thought would be to not write the ssApp/SetupS files in the <AppPath> folder at all, but instead write them to a folder in C:\Windows. You're already writing a LastXP folder there (THAT name should be updated, too) to keep an empty start menu structure. Why not keep a parallel structure with the ssApp/SetupS files for the SetupS installed programs? That way, even if we do add an uninstall function of some type, and I think we should, if someone uses another mechanism to uninstall the app, it will be able to remove the app cleanly, with no left-over files in the <AppPath> folder. Since the ssApp/SetupS files are not "official" app files, the various other cleaner programs probably won't show them as left-over either, so there will still be a need for the SuperLLclean type cleaner, but to the casual observer I think it will look cleaner. That will also allow the possibility, though I don't know why someone would want to, of uninstalling SetupS from your system, deleting the LastXP folder completely, and not effecting the function of the app. Or is there some kind of important interaction that I'm not aware of?

[The Freezer]

[...] Why not keep a parallel structure with the ssApp/SetupS files for the SetupS installed programs?

This idea definitely has possibilities. I'm thinking though the only file needed copied is just the .app file -- either renamed or placed into a folder -- as that would have all the info a ssUninstaller (an unSetupS?) would need such as shortcuts that can be searched for and of course the <AppPath> to delete entirely.

[...] That will also allow the possibility, though I don't know why someone would want to, of uninstalling SetupS from your system, deleting the LastXP folder completely, and not effecting the function of the app. Or is there some kind of important interaction that I'm not aware of?

Nope, SetupS can be harmlessly uninstalled from the system at anytime. In fact, it is fully ppApp'able -- even down to the registry changes like Sendto, etc. Checkout the latest ssWPI package for an example of that

[bphlpt]

I'm thinking though the only file needed copied is just the .app file -- either renamed or placed into a folder -- as that would have all the info a ssUninstaller (an unSetupS?) would need such as shortcuts that can be searched for and of course the <AppPath> to delete entirely.

Did you mean that the .app file is the only one needed for the ssUninstaller, or it's the only one needed to be "installed" period? If the .app file is the only one needed, then why with the latest ssApp install of 7-Zip 9.20 were the following files copied to the <AppPath> folder?
ssApp.app
ssApp.ico
ssApp.jpg
ssApp.png

I'm not aware of any use for the .ico, .jpg, and .png except by ssWPI, and I didn't think that ssWPI would look for those files in the <AppPath> folder, anyway. I was saying keep any files that ssUninstaller, or any other LastOS/ssTek program needs somewhere else besides in the <AppPath> folder both to make uninstalls cleaner and to be less likely to confuse the user. Seeing them there confused me when I first saw them in an early crabdance build. (See I told you I was a nit-picker sometimes. ) Looking in C:\Windows you can see that plenty of other software suppliers clutter it up. Why should we be any different? heh heh Of course, we'll do a much neater job of it. If we keep everything within a single LastOS folder, I think that should be fine. I now climb off my soapbox and high horse, hoping like hell I didn't just stick my foot in my mouth and embarrass myself.

Nope, SetupS can be harmlessly uninstalled from the system at anytime. In fact, it is fully ppApp'able -- even down to the registry changes like Sendto, etc. Checkout the latest ssWPI package for an example of that

Thanks for the confirmation.

Cheers and Regards