Miscellaneous discussion (SetupS)

Discussion in 'Discussion' started by Trouba, Jul 6, 2011.

  1. The Freezer

    The Freezer Just this guy, you know Staff Member

    Thanks. I forgot about a leading (or trailing) underscore character -- it was left over from "fix-up" work it was using with <Title> to derive part of the deployment package filenames.

    Sorry about that. I'll add an exception rule here shortly (for leading/trailing dots and dashes as well as underscores).
     
  2. Trouba

    Trouba Administrator Staff Member

    Thanks for the fix, luckily I made a dual-arch ppApp of NTLite with the .21 version of SetupS last night so I caught it right away before Glenn turned on his auto-app maker and rolled out 50 apps :D
     
    Glenn and The Freezer like this.
  3. Trouba

    Trouba Administrator Staff Member

    Yep, looks like it's working properly now (y)
     
  4. The Freezer

    The Freezer Just this guy, you know Staff Member

    Surprising how many installers USSF (v1.5.0.0) still detects considering how old it is (circa 2011?). Currently, ssEditor relies heavily on SFK -- mainly because of all the extra information it obtains about the installer. TrID and its signature-defs are updated much more frequently than SFK, but not as much info about the installer. In fact, TrID returns results in descending probability of the type of installer it is. PEiD has had its signature file updated by different groups over the years, but it too is now outdated.

    One annoying aspect of USSF though was its stay-on-top focus and I remember USSF had originally been coded in AutoIt3. Should be super-easy then to turn off or hide USSF while in use; and possibly in the process update/improve it myself, right?

    So I did a little digging around on USSF. I found it had been pretty much abandoned since birth with several folks updating it over the years with many improvements and features -- such as command-line arguments and integrating PEiD. Ultimately one of its maintainers (Kelsenellenelvian or simply Kels) had taken full control over its source for inclusion in his WPI project but made it closed-source in the process. At first it was a separate utility within WPI's tools folder (probably around v1.5.0.0, its last known release) before being fully integrated into it. USSF is now missing from the tools folder but still being used by WPI itself -- it even has a USSF button next to the installer-picker. I suspect this happened sometime after USSF was ported to JavaScript which I believe is what WPI is mainly code in.

    Okay, maybe not so easy to bring USSF up-to-date. LOL
     
  5. Trouba

    Trouba Administrator Staff Member

    I've now read several conflicting account of how WPI got created. Was WPI first or was ssWPI first, and who got what from where? I know Glenn talked about this a bit some time ago, but I still wasn't clear on the history of (ss)WPI. I know I tried talking to Kels about it once or twice, but Kels seems to be a person that will just stop responding once you say something he doesn't like or he doesn't deem useful or whatever. Making things closed-source doesn't really go towards being on the right side of things either, but I don't know much more about these matters although I can say he's not the easiest to communicate with in my experience.
     
  6. The Freezer

    The Freezer Just this guy, you know Staff Member

    Ironically, USSF is now open-source once again -- as a JavaScript used by WPI ;)

    Actually Kels wasn't the original creator of WPI. Apparently, it was created sometime in 2003 and it too was updated by a series of maintainers until Kels got involved in 2005. BP gets the credit for discovering all this. It's likely WPI and ssWPI were developed in parallel since their goals were dissimilar. WPI was simply a post-OS install for apps whereas ssWPI was both a pre-OS and a post-OS install for apps.
     
    bphlpt likes this.
  7. Trouba

    Trouba Administrator Staff Member

    So a guy called "Whimsy" is the one who first came up with WPI in 2003.. cool.

    We'll see what Glenn has to say, unless he's in over his head with that subscription-based OS scheme :D
     
    The Freezer likes this.
  8. Glenn

    Glenn Administrator Staff Member

    Nah the WPI was many years before ssWPI if it were made in 2003, early 2007 would have been the first as LastXP v13 had no selection menu (all inclusive or install-able one at a time from SFX's)

    LastXP v12 Complete was in the wild by 2006-11-14

    LastXP v13 was in the wild a month later 2006-12-15:
    http://phantomp2p.com/forum/viewtopic.php?f=25&t=5461

    It was between LastXP v14 and v15 over the following 2 months that SetupS and ssWPI were created in early 2007.

    ------

    2007-08-18 and through the next 3 weeks was the date I constructed MGP v1.23 which had the completed SetupS with .ppg methods supported.
     
    Last edited: Jun 2, 2016
  9. The Freezer

    The Freezer Just this guy, you know Staff Member

    Sounds about right. Early 2007 was around the time I started experimenting with the various XP-mods because of the surge in requests I was getting from the big Vista backlash that was going on at the time. And back then there sure was a lot of XP-mods to sift through; but NightWolf's LastXP and eXPerience's TinyXP were the standouts.

    And of course shortly after that I would also stumble upon SetupS -- in its VB6 incarnation -- and its incredible usefulness. :)
     
    Glenn likes this.
  10. Trouba

    Trouba Administrator Staff Member

    Funny, 2007 sounds so recent, I guess it's hard to imagine most people were still using XP then, but it must be that we were.

    Freezer, I just tried installing AIMP ssApp (just uploaded it to repo so you can test) and it is not dumping the Patch.7z files in the correct directory. The patch file is creating an AIMP dir in "Program Files" on a x64 OS -- so the Patch.7z contents are not getting placed in the right directory, which should be in "Program Files (x86)". I had not noticed this problem before so maybe it's something about newer SetupS versions? Or it's just not detecting the correct install dir for the AIMP installer in general anymore.
     
  11. Glenn

    Glenn Administrator Staff Member

    I noticed that you have a ssApp.cmd with
    Code:
    %Extract% "%SourcePath%\_PatchADR.7z" -o"%AppData%"
    That isn't a file that exists.

    Your ssApp.app has

    ReleaseVersion=aimp_4.02.1721.exe

    But apart from that, yeah freezer if you could check for an existing C:\Program Files (x86)\GivenPath when "AppPath=%ProgramFiles%\.." is given as I noticed that same behavior and even the ssApp.app file and jpg,ico and png get placed into the %ProgramFiles%\ aka "C:\Program Files" even tho the app installed to "C:\Program Files (x86)\" the app is NOT a x86 only app so that is why we don't specify it as one. Safer than us using a different Variable substitution as when you install on a x86 OS it actually IS "C:\Program Files\" so it would be easy to test if the folder exists in the (x86) before having to make it for a ssApp structure to copy things like the patch etc to it.
     
    The Freezer likes this.
  12. Trouba

    Trouba Administrator Staff Member

    Yeah, true, _PatchADC.7z was a file I included in a personal version of AIMP ssApp, where I included profile stuff (like I did in the ppApp) but I wanted to keep the ssApp less tweaked for general use. I used to have 2 versions of the ssApp but since I prefer the ppApp I got rid of the personal ssApp versions, but forgot to remove the ssApp.cmd.
     
  13. The Freezer

    The Freezer Just this guy, you know Staff Member

    Yes, thank you. x64 behavior has always been "weaker" for ssApp's than ppApp's. One makes the mistaken assumption that the installers will naturally take care of proper arch installation -- that and at the time it was difficult to test on non-virtualized x64 machines.

    So it helps to have specific examples such as this with AIMP where it fails to install properly or completely.
     
    Glenn likes this.
  14. The Freezer

    The Freezer Just this guy, you know Staff Member

    Weird. I can't get Setups to repeat this problem. Everything's been going to the "Program Files (x86)\AIMP" folder properly -- and no "Program Files\AIMP" is ever created. Tested on Windows 10 Pro x64 using the latest (v16.6.1.0) and your AIMP with the Patch.7z

    I did notice an unrelated problem with SetupS and Windows 10. AutoIt's Run/Runwait command doesn't ever launch some tools with no explanation or error why not. Shell/Shellwait works okay with those; But Shell doesn't return an associated PID like Run does.:what:

    So far, I've only found one tool that doesn't work with Run (skf.exe). I'm still searching for others. Obviously, 7-Zip still works okay; otherwise we'd have noticed long before this! LOL
     
  15. Trouba

    Trouba Administrator Staff Member

    I do use Win7 x64, if that could even matter.

    Yeah it wouldn't be v16.x of 7-Zip or anything I would think? Weird, you may try it on Win7 x64 and see if you could duplicate the problem there. But Glenn was saying he was experiencing it too, and I think he uses Win10 x64. Did you try it with latest Win10 build or LTSB build (if that could even matter)?
     
  16. The Freezer

    The Freezer Just this guy, you know Staff Member

    Nah. It was just the generic-free-upgrade version.
     
  17. Glenn

    Glenn Administrator Staff Member

    skf.exe doesn't work because it's got Administrator flag set, so the only way it will work is if SetupS or SetupS Editor is running as Administrator (so impossible to debug test it - without setting AutoIt.exe to run as admin anyway). ssEditor is already set to run as admin so a non problem for my testing.
     
  18. Glenn

    Glenn Administrator Staff Member

    I am not having a problem when I double click the AIMP ssApp, so I am thinking it may be related to calling SetupS from ssWPI?
     
  19. Glenn

    Glenn Administrator Staff Member

    I am getting folders created just to put the ssApp files in to tho (for items like DirectX, Last10 Tweaks, 200 Fonts ssApp) These items do not need a folder, I think I even saw a Nonething folder when I installed my PC but I removed that manually already.
     
  20. The Freezer

    The Freezer Just this guy, you know Staff Member

    LOL, actually a feature by design. Those are "placeholders" to tell if an ssApp has been installed, what version, etc. -- mainly for ssWPI/ssGooey -- and ssRegenerator uses them too. ppApps have similar folders with a similar function such as for tweaks, addon's, etc.

    Nonething's purpose escapes me, at the moment. Something along the same lines, I think.
     
  21. The Freezer

    The Freezer Just this guy, you know Staff Member

    Nonething has been for a while now a post-processing option -- probably nothing to do with creating "Nonething" folders, though:
    • Make Nonething App - Suppress SetupS related files. Basically, this prevents creation of the Aux files (screenshot, fader, etc.), advanced startmenu shortcuts, folder icons, and the .app-file. This also means that the app will be rendered invisible or nonexistent to SetupS and ssWPI.
     
  22. The Freezer

    The Freezer Just this guy, you know Staff Member

    Thanks, gives me a new direction to test with a compiled ssEditor. Though the workaround I made works nicely too -- for debug testing within AutoIt. Compiled should work also. But I'll test anyway.

    Is this a behavior unique (new) to Windows 10? I've heard people having issues running some apps unless they "Run as administrator". Also maybe it started with Windows 8/8.1. I never tested skf.exe with those after I added it to ssEditor.
     
  23. The Freezer

    The Freezer Just this guy, you know Staff Member

    So far these have checked out okay:
    • Win10_Pro_x64 (Vanilla)
    • Win7-Ult-SP1-x64 (Vanilla)
    • Win7-Ult-SP1-x64-enUS-Lite-dotNET452-2015.05.20 (Lite)
    • Win10-Ent-LTSB-x64-2015.07.10 (Generation2)
    These are the (brief) checks I do to test:
    • The contents of Patch.7z -- "Program Files (x86)\AIMP\Encoders" has lame_enc.dll, faac, .\qaac\, etc.
    • No "Program Files\AIMP" folder
    Is, as Glenn said, AIMP getting installed via ssWPI? Though, I'm not sure how or why that would be an issue... :what:
     
  24. Glenn

    Glenn Administrator Staff Member

    It is an issue since UAC was embedded in Windows 7, the reason it's not a problem in Windows 7 is because your probably using the built in Administrator account - meaning everything you run is as Administrator ;) So from Win 8.0 they disabled anyone from using the Built in Administrator - thus the issue.
     
    The Freezer likes this.
  25. Trouba

    Trouba Administrator Staff Member

    Well, this is just bizarre... I just tried it again and Patch.7z installs correctly into "Program Files (x86)"... :confused: (AIMP dir not getting created in "Program Files" either.)

    I swear it wasn't doing this before, I tried it at least 3 or 4 times and it kept installing Patch.7z to "Program Files" instead. In fact, I was going to show you a video snapshot of it this morning so you could see it with your own eyes, only to find it working somehow.

    I sure hate to see you waste time on this but I can't reproduce it now. I tried it 4 times and every time it's installing correctly. I thought computers weren't supposed to have good and bad days?

    PS: I was just doing double-click installs both when it failed before and this morning when it worked correctly, I didn't use ssWPI at any time.
     
    The Freezer likes this.

Share This Page