Miscellaneous discussion (SetupS)

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

  1. Glenn

    Glenn Administrator

    Code:
    [File Explorer.lnk.WIN_10]
    Target=
    Description=Displays the files and folders on your computer.
    Icon=%windir%\explorer.exe
    Default=%Programs%\System Tools
    Catalog=
    Shortcut=
    [Run.lnk.WIN_10]
    Target=
    Icon=%windir%\system32\shell32.dll
    Index=-25
    Default=%Programs%\System Tools
    Catalog=
    Shortcut=
    Sorry I don't have Quick Assist, I never removed it so don't know why I don't, running Win 10 Pro x64.
     
  2. Glenn

    Glenn Administrator

    Here is the actual .lnk's if the above is incomplete, dunno why the target is blank.
     

    Attached Files:

  3. The Freezer

    The Freezer Lead Developer for SetupS Staff Member

    Universal Apps, maybe?

    If I remember correctly, peeking at the properties of a Universal app's shortcut will show the target is disabled.
     
    Glenn likes this.
  4. Glenn

    Glenn Administrator

    I just noticed that if you install a ppGame it will create a StartIn= in the link target section even if it never had one set. This would be fine, but with ppGames you can actually move them around out of the X:\ppGames\ folder to Y:\ppGames\ if the HDD is getting full, this stops it from working with ssWPI or any shortcuts being made as the drive letter for %ppGames% is different to the manually move to drive. Not sure why you would want a StartIn= when the exe is in the root path anyway, that happens automatically.

    Up to you if you think it's worth changing this, just something I noticed.
     
  5. The Freezer

    The Freezer Lead Developer for SetupS Staff Member

    Yeah, I see what you mean. But, I, for the life of me, cannot remember what possible reason I had for doing that. Most of the time Startin is the same as %AppPath%; and if left blank defaults to %AppPath% anyway. Plus, all the paths -- Target, Icon, etc.even StartIn -- are all relative to the %AppPath%. The only mandatory (non-blank) requirements for a shortcut are its Link Name and Target. :what:

    I'll take a closer look, I can't imagine that that was a random decision.
     
    Glenn likes this.
  6. Glenn

    Glenn Administrator

    I hope you mean as well as.. because I will have a heap of apps to go and update otherwise. So do you still support reading the old flag for backwards compatibility?
     
  7. The Freezer

    The Freezer Lead Developer for SetupS Staff Member

    Yes, of course. :)

    In fact, the previous version(s) had supported the flags as "Is_x86"/"Is_x64" and not as "Is_86"/"Is_64" so they would end-up creating both shortcuts (with the same name) usually the x64 version being the "survivor" and not working on an x86 OSArch. A re-save with ssEditor (or a manual edit changing them to "Is_x86"/"Is_x64") would actually "fix" the bug using a previous version of SetupS. But I'm not certain how long it'd been around or how it'd gone for so long without being noticed. And why did I choose those strings to begin with? They are not consistent with the convention I had already established with the folder naming or the OSArch gates used elsewhere in the specs.

    Bottom-line is that those odd flags, "Is_86"/"Is_64", were what was causing the real the bug.

    A weird bug for sure; but fear not. I prepared the latest to work using either set of flags.
     
    bphlpt and Glenn like this.
  8. The Freezer

    The Freezer Lead Developer for SetupS Staff Member

    While I'm at it, might not be a bad idea to add #Is_x86# / #Is_x64# as well ... would be even more consistent and even less confusing.

    I'm also wondering how many ppApps are using Is_86 / Is_64 flags. It's proving a bit of a challenge as the Type 2b's (2>2) are clearly marked with "_DualArch"; but the Type 2a's (2>1) are not obvious from their filenames and have to be dismantled to reveal the _x86 & _x64 folder structures and/or the shortcut def flags for dual-arches. :what:
     
    Trouba likes this.
  9. The Freezer

    The Freezer Lead Developer for SetupS Staff Member

    So far I've only found 2 ppApps using the "Is_86" / "Is_64" flags. The others were using "Is_x86" / "Is_x64" flags.

    I would say they were anomalies except the "Is_86" / "Is_64" flags are mentioned in the ssTek help file included with SetupS (the previous version -- I've updated the references for v17.12.3.0).

    That's a good thing -- and maybe why it went unnoticed for so long -- because it was those flags ("Is_86" / "Is_64") that were causing the bug.
     
  10. Trouba

    Trouba Administrator Staff Member

    I've only ever used "Is_x64" / "Is_x86", I'm pretty sure.
     

Share This Page