use msix/msixbundles for modern msvc builds

[getchoo]

this replaces the nsis installer for modern msvc builds with an msix package. this does not yet implement the sandboxing capabilities possible with the format, as that will require a bit of rewriting. i still plan to do this, but would like to have the basic infrastructure setup beforehand.

new. cool stuff

msix (in this pr) will allow us to:

• have a more user friendly installer
  • instead of an ugly exe you download that takes you through a few menus, the msix package simply opens, and you hit install
• combine the arm64 and x64 installers into one
  • see msixbundles
• implement autoupdates
  • this is the main reason why this is draft right now, as i'm still figuring this out :p
  • see Using an embedded App Installer file to update your app
• remove the need to install vc++ redistributable separately
  • msix files can bundle dependencies. including vc++ redist. the name is weird because it says uwp, but it works for win32 applications as well
• resolve Windows updater #94 + improve windows support #167 (for our primary builds at least) and open the door for Publish to Microsoft Store #995 if we would ever want to do that
  • a lot of issues relating to this wow

tradeoffs

there are some tradeoffs here though, including:

• not being able to specify an install location with the installer
  • this is a regression, however given the advantages and the rarity of needing to install the launcher itself somewhere other than your C drive, i don't think this is too bad
• windows versions earlier than windows 10 v2004/20H1 v1809/LTSC 2019 will be unable to use this
  • this is due to win32 runtime behavior not being supported until then, and given that the latest ltsc is still supported and 20H1 has been EOL for a while, i think this is also acceptable win32 runtime behavior is no longer used here so this isn't an issue. instead we use packagedClassicApp/windows.fullTrustApplication which is supported by v1809/LTSC 2019 and up
  • this is due to AppInstaller not being supported in early versions

most of these could be avoided by still providing a setup.exe, however with auto updating and sandboxing (hopefully) in the future, i think it's best if we push this as the primary and only installer for modern msvc builds. plus, for the sake of compatibility with much older windows versions (and slightly newer 10 releases prior to 20H1 1809), legacy and mingw builds will still create a setup.exe. i feel this is a good compromise for users who would rather stick with a setup.exe on modern windows or haven't updated.

TODO

here's a nice list to help track progress :)

• msix installers
• msix signing
• single msixbundle for arm64/x64 installers
• auto updates with app installer
• install vc++redist automatically

Known Issue

these come from the testing we've done on discord

• NewLaunch.jar can't be accessed by the jvm (seems to only happen on quilt/fabric...not sure why yet)
• accent colors are used as a background (should be transparent)
• unvirtualizedResources capability is blocked on some devices
  • based on my testing and some feedback, this seems to be extremely rare and mainly occurs on W10 21H2
  • we can't really avoid this, so documentation will need to be written on allowing installation of apps with these capabilities

[getchoo]

msixbundle is done!
https://github.com/PrismLauncher/PrismLauncher/actions/runs/5233072078

[getchoo]

with the appinstaller (mostly) completed the package should be able to auto update now using the same msixbundle created previously. prismUpdate.AppInstaller should be the file distributed to users, as it is what handles the updates.

this requires a few things though:

• the msixbundle and appinstaller must be available online

  • this is so that the appinstaller on the users device can download newer appinstallers as well as the msixbundle itself
  • i'm not sure how we should go about this with builds from develop. so far, i've locked appxinstallers to a specific version of prism based on the run id of the workflow. i was thinking may have a way to automatically upload these and keep them available for x amount of time? we could also have 2 appinstallers: one targeting the latest commit, and another for stable, allowing users to get auto updates for both
  • maintainers should read this guide on distributing appinstallers
  • this should be completed and tested before this pr is merged, as the local testing i can do it limited.

• figuring out what to do with prs

  • as secrets aren't available to workflows in pr runs, we can't sign any of these packages and thus they are uninstallable without some weird stuff. this isn't great for testing and i don't know a solution here besides maybe using azure or something similar?
  • another solution: we just disable them in prs

[DioEgizio]

windows versions earlier than windows 10 v2004/20H1 will be unable to use this

And this is why I think we should keep the nsis installer too (totally not because I use ltsc 2019 on some PCs)

[getchoo]

(totally not because I use ltsc 2019 on some PCs)

i might be wrong, but i'm pretty sure mainline support for ltsc 2019 this year no? i think it might be time to upgrade

but in all seriousness, i see your point - not just for older releases, but just for backwards compatibility in general. as the main method of distribution for our flagship build, it will be pretty confusing for people if it no longer works for them or if they don't see the setup.exe they've been used to for so long. however, i really do think this temporary problem is worth it.

with the possibility of sandboxing in the future, auto updates now, and a simplified install process, we should be pushing users towards this. by keeping the setup.exe for our recommended build, i fear that a good number of users will just stick with it and not be able to to take advantage of these features. i also think this will have to happen anyways, especially once sandboxing is implemented so we can make it a default when installing prism; it might be better to "rip off the band aid" now, so to speak

i think that with proper documentation linked in the github release and blogpost on the website, this can be an easy transition that will pay off in the future. and after all, a vast majority of users are most likely on versions > 20h1, and there are still regular x64 setup.exes available with mingw

[DioEgizio]

Also add the new files in https://github.com/PrismLauncher/PrismLauncher/blob/develop/.github/workflows/trigger_release.yml

[DioEgizio]

(totally not because I use ltsc 2019 on some PCs)

i might be wrong, but i'm pretty sure mainline support for ltsc 2019 this year no? i think it might be time to upgrade

but in all seriousness, i see your point - not just for older releases, but just for backwards compatibility in general. as the main method of distribution for our flagship build, it will be pretty confusing for people if it no longer works for them or if they don't see the setup.exe they've been used to for so long. however, i really do think this temporary problem is worth it.

with the possibility of sandboxing in the future, auto updates now, and a simplified install process, we should be pushing users towards this. by keeping the setup.exe for our recommended build, i fear that a good number of users will just stick with it and not be able to to take advantage of these features. i also think this will have to happen anyways, especially once sandboxing is implemented so we can make it a default when installing prism; it might be better to "rip off the band aid" now, so to speak

i think that with proper documentation linked in the github release and blogpost on the website, this can be an easy transition that will pay off in the future. and after all, a vast majority of users are most likely on versions > 20h1, and there are still regular x64 setup.exes available with mingw

TIL we're in 2029 (https://learn.microsoft.com/en-us/lifecycle/products/windows-10-enterprise-ltsc-2019)

[getchoo]

TIL we're in 2029 (https://learn.microsoft.com/en-us/lifecycle/products/windows-10-enterprise-ltsc-2019)

hey i did say mainline
...but man, off by a year :waaa:

[TayouVR]

I do think keeping the old installer around is good too. At least for now.

[getchoo]

Also I think we'll have to change https://github.com/PrismLauncher/PrismLauncher/blob/develop/.github/workflows/winget.yml now

done :)

[DioEgizio]

I still think we should have the setup.exe for modern builds for people who want to change paths but especially for PRs and devbuilds. Like I wanted to try this pr but looks like for self-signing I need the entire msvc

[getchoo]

I still think we should have the setup.exe for modern builds for people who want to change paths

im a still a bit iffy on this since it's a small niche that could cause a bit of confusion when the transition happens - like for example, we announce auto-updates, people use the setup.exe they have been using, but then don't get auto updates. come to think of it though, making the msix the default on the site could hopefully avoid some of this, as well as saying something like "hey! you'll need to uninstall your current version of prism and then use the msix just this once"

especially for PRs and devbuilds

yeah we really can't do much with prs (though personally i just use the zip instead of the setup.exe), but for dev builds i was thinking of making a separate app installer specifically for develop. it'd make it easier than ever for people to have a rolling version of prism on windows (this would already work, and could use automation similar to what we'll do for actual releases)

Like I wanted to try this pr but looks like for self-signing I need the entire msvc

technically it's just the windows sdk (TIL), but yeah...i didn't realize this until now. this does suck, especially with how you have to make your own cert :/

i'll add back the setup.exe, but i think with that we should really push the point that it's probably not something you should be using when installing modern builds

[DioEgizio]

Perhaps we could say on the website to use the msix and maybe we could put the setup as an extra option but as an "advanced" option like we do rn for the system install zip

[getchoo]

yeah i'd be up for that idea :)

[getchoo]

tests are ongoing in feature/msix

[getchoo]

backported all of the work done in features/msix. i'm going to do a general test tomorrow and this should hopefully be good to go! all that would be left is automating the upload of prismlauncher.AppInstaller and the msixbundle to a server somewhere 🥳

[Scrumplex]

might need more changes as #981 was merged.

See #981 (comment)

[DioEgizio]

It needs changes anyways, I remember there are issues with running MC rn

[Trial97]

@getchoo can we remove this PR from 8.0 milestone?
I removed it for now. If you think this is ready for 8.0 then add it back.

[getchoo]

we can hopefully try this again one day, but for now we can't move forward without having ms signing certs

marking as draft