Miscellaneous discussion (SetupS)

Gasp! He's figgered me out, RON!! LOL

Seriously, you've gotten the gist of it right there. SetupS plays both ways nicely and with the ssApp flavor we can take advantage of some stuff that would be difficult (or impossible) to do as a ppApp.

 

Also, as you've probably already discovered, there are subtle but distinct differences between the SourceCode and Developers packs.

The reason I did that?

One was to keep within the guidelines of GPLv3 (the SourceCode pack) so that it is completely transparent and straight forward (but for that version only). With some difficulty one should be able to compile a working suite.

Unfortunately, in order to provide a way to easily continue with ongoing development -- and as convenient "backup" of my work -- I have also created the far more complete "Developers pack" so that anyone else can pick up right where I left off (if need be) with little or no difficulty. The trouble with using the Developers Pack for the GPLv3 is that there's far more stuff than what's really required and most importantly the source material from the Developers Pack doesn't designate any copyright ownership with which to bind the GPL.

 

Creating ppApp suites for one. SetupS has its hands tied with what it can do with that first shortcut from <ShortcutS> or <ShortcutNamesKeep>. But in a suite, each app will likely have very different requirements. For example, there will be difficulties with File Associations ("Open with"). Sure we can do file associations with each shortcut defined in <ShortcutS> now -- but there was a time we couldn't -- and that's for "Open with" type of associations only. What about "Edit with" (even though those could probably be set with the <Registry>, of course)?

The biggest thing right now is that we cannot create different shortcut locations for each app in a suite (Desktop, Startup, Sendto, QuickLaunch, etc.); nor can we create different startmenu destinations <Catalog> for each app either.

Actually if you check the source code you'll see I've had designs to do something about those last two shortcomings; but time just never really allowed me to work on them

Bottom-line, it's almost as if each app in a suite would be better off as its own separate ppApp.

 

Even that can be handled with clever use of <Registry>. See my Unlocker ppApp as an example of that's done

EDIT: oops, fixed the link... didn't realize Trouba had updated that with his version which doesn't do the uninstall trick

 

Where do you see this (I'm curious)? The recursive functions will go as deep as there are system resources to allow it.

What I did limit on depth scanning was in searching for .app-files with the assumption that there would be no (useful) .app-files any deeper than the folder in which one is found. For example, "C:\Windows\System32\Famatech\Radmin" has a ssApp.app and there could be folders deeper that have ssApp.app files ("C:\Windows\System32\Famatech\Radmin\Backup") but that we really don't care about.

This had the unfortunate side-effect that if an .app-file was found for example in "C:\Programs Files" that it would not search for any more apps below there.

 

BP, either after or before you put the new pan in, make some bleach-water (don't use straight bleach) and let it run down your AC drain pipe that's normally connected to your pan. After a while these pipes get clogged with nasty stuff, especially in the heat. The bleach will kill all the bacteria and flush some of the sludge out. You can also do this after you put the new pan in place, just poor the mixture into the pan and it will drain through the drain pipe (this way you can also test against any leaks). I had to unclog the drain pipe for mine a couple of years ago, but since they made a stupid 90 degree turn on the attic, I couldn't get through there with a rooter. Finally I was able to feed the long rooter from the outside all the way in and finally I got it flush out and you wouldn't believe the sludge that came out of it.

Take care though, the heat combined with the bleach fumes will knock you out. It almost did me that time, partly because of space confinements and the way they ran pipes and ducts I could only get to where I needed to be and rest on one leg while I tried to clean the drain. Even compressed air wouldn't knock the sludge out. Then the bleach and heat got to me and I knew I had to get out... but couldn't immediately because I was completely hemmed in... almost fell down the attic stairs gasping for air... so be careful, and please work in the early mornings only...

 

So I'm looking over that Kels Uber Pack (btw, nice work, Xan)... and wow, what a messy installer that is:

• Throws .exe's all over the place (mostly "System32" but some "C:\Windows" too),
• creates shortcuts in a generic startmenu source folder ("Utilities", seriously?), and
• has no uninstaller whatsoever... which means you're stuck trying to figure out how to remove the files (which ones and from where and whatnot) .

No wonder SetupS was having so much trouble figuring out this one! LOL

Anyway, I tweaked the upcoming revision to use the source %AppPath% if all its methods and searches can't come up with an adequate one -- just as is done already with the #cmd# md "%AppPath% in <Assembly>; but built-in now.

 

c0de sent me a little runtime package he was working on, and in trying to figure out how to make it 'install' to a temp directory, register the .dll's, and delete it afterwards, I found that SetupS in a certain configuration of the .app file actually seemed to take on the name of the app in <Title> from which to create an install directory...? The only mention of "!LastOS Runtimes" in the entire app and/or .app file was in the <Title> section... and it went ahead and created a folder in Program Files called "!LastOS.Runtimes" which kind of surprised me. Is this intentional? Yes, a true AppPath was missing in the .app file, and it was one of the stages of trying to make that app work, but I did not expect that. But in the end I got to work by giving it %ProgramFiles%\Nonething which extracts and registers in the temp directory (from a "ssApp.7z"), then deletes it, so that works out. But just wanted to mention this in case you need to be aware of this for the next SetupS version.

 

Thanks for the translation Not a bad feature, because it can also give you feedback on what you're NOT trying to achieve, as I found out with the runtimes app As long as it doesn't get too invasive and start re-writing app files too much it will be a good thing.

 

See now you have choice. Use NoneThing and your app will forever show up on ssWPI no matter what. Not and ssWPI can now hide apps you've already installed. Definitely yes, this is a good thing. For example, maybe I can't remember if I installed that DotNet AIO -- so do I really want to sit through a very long install of that?!?

 

Yes, I think I see what you mean. If you allow it to write folders to Program Files or another location, you can keep the .app file there and it will tell ssWPI it's already installed -- right? How about temp stuff then, will it keep all the runtime dll's installed in a certain location then or could we still have those files deleted after they get registered?

 

i have a idea about the nonething apps that are used, instend of %ProgramFiles%\!LastOS Runtimes\ssApp.app sayin thats how sswpi will see that the app has been installed , let sswpi create a .ini file either in program file or even where sswpi.exe is ran lets say installedapps.ini ,and when the user selects that app it installs the app and then creates that ini file lettin sswpi know its been installed . ??? what u think ???

installedApps.ini

Code:

%SetupS%\!LastOS.Runtimes_v7_ssApp.apz

edit: That way the %ProgramFiles%\nonething path can used more often and there wont be no extra folders added to program file

 

gawd:

 

that bad lol

 

Freezer, run through this for me and explain what it is I'm missing.

You install the DotNetAIO. Whoever made it didn't put an install path or shortcuts, since they don't apply, and they didn't use NoneThing. When SetupS installs it, since NoneThing was not used, it creates a folder in %ProgramFiles% to store the .app file so ssWPI will know it has been installed. So far, all well and good.

Later, you run ssWPI again, and as you said, you don't remember whether you installed the DotNetAIO the last time. The .app file is out there, somewhere, but since ssWPI ONLY looks for the app in the install path, and there is NOT one, then how does ssWPI know where to look for the .app file? You have made SetupS run through many potential choices so that it can put the .app file in an appropriate spot, and that's great, but I wish there was a way for you to then let ssWPI know where the file ended up so that ssWPI does not have to recreate the wheel and go through the same process in looking for it, which it currently doesn't, unless RON added it in when I wasn't looking.

When SetupS rewrites the .app file in whatever %ProgramFile% location, does it write that location as the Install Path in the .app file? If so, then if the app author built the app correctly, meaning that he installed it then copied the "new" version of the .app file back into the source before distributing it, then ssWPI will know where to look and everything's great, right? And if he didn't copy the "new" .app file back, then tough beans on whoever uses that app because ssWPI will never know if it's been installed or not. Did I miss anything? Is this what I was not taking into account when you kept saying that ssWPI's checks for Install Path were sufficient?

 

LOL No c0d3, it's just that I've been asking Freezer to add an InstallAttempts log file to SetupS ever since I got involved with ssWPI, if not before. The reason that IF a log file is created that SetupS should be the one to write it, is that you can install an app just by double clicking it, without ssWPI ever being involved, but SetupS is ALWAYS used to install an ssTek app.

 

well the only reason i say have sswpi write the .ini files is because sswpi is where the user is installin it from ,get what im sayin?

edit: because lets say u just click on the apz file and not use sswpi to install it , then when u run sswpi how will it know its installed ?

 

Exactly.

Unless, this is true...

But I don't know if that is indeed what happens.

 

I think he did. But it was only a simple check for "%AppPath%\<Title>" (with some filters, etc. thrown in). In hindsight, since ssWPI can't show anything without a <Title> anyway, that is probably as far as I needed to have SetupS go too. Oh well.

But.... The Thing I'm really trying to encourage is that folks set complete <AppPath>'s from the get-go and none of this is a problem, natch. (see because then the <AppPath> is what it needs to be at the source .app-file rather than a possible mystery at the install-path)

Also, for those electing to use ssEditor will find some major help along those lines as well