You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 5, 2024. It is now read-only.
Now that Squirrel is on dotnet 6, there is no reason we can't build cross-platform binaries and consider adding support for other operating systems.
Windows arm64
There are not a lot of code changes required to support arm64 properly, most of this is just recompiling binaries. There also should not be any compatibility issues creating x64 packages on arm, or vice versa.
To support applications being deployed to arm64:
Add appropriate enumerations to RuntimeCpu
Update AssemblyRuntimeInfo to check for ARM when detecting OS machine architecture
[ ] Compile StubExecutable.exe, Setup.exe, Update.exe for arm64. (they are all x86 at the moment, technically windows on arm supports x86 emulation, so maybe we could skip this)(x86 binaries can be virtualised on x64 and arm64)
Update SquirrelCli.Releasify to check for incompatibilities between x86/x64 and ARM when building packages and store the correct machine architecture into the package metadata.
[ ] Also update SquirrelCli.Releasify to use the appropriate Setup86 or SetupArm64 (and Update86/etc...) depending on the package architecture.(not needed since we are only building x86)
Update error message logic in Update.Setup when checking current architecture
[ ] Compile Squirrel.exe for arm64(not needed as Squirrel.exe is now a cross-platform csq tool)
Add arm64 variants of other vendor binaries or confirm that they can run successfully on arm64 (rcedit, signtool, singlefilehost)
macOS
I do not believe we can support building packages for macOS on windows as codesign and xcrun/altool is not available. Similar issues trying to build windows packages from MacOS, but we can use Wine to fill in some of the gaps. I will not support installing dotnet runtimes on linux/macos, so only self-contained apps will be supported.
We can create universal binaries for mac that work natively for more than one operating system / cpu architecture using lipo, this seems to be preferred instead of having separate downloads in Apple's ecosystem. Example:
We should probably bundle RID osx.10.12-x64 and osx.11.0-arm64 at a minimum to cover off the two widely used CPU architectures.
We install to %localappdata% on windows, the closest thing on macos is probably %userprofile%/Applications which seems to be uncommon but used by some.
Comb through Utility, make sure all the file paths, process starts, process enumeration etc have abstractions for macos
Cross-platform ZIP implementation to replace 7z
Remove MsDelta logic, we have bsdiff anyway and it's faster
Review temporary paths used by UpdateManager, these can not be stored in the app folder like we do on Windows.
Replace the "Apply Updates" logic, remove shortcuts, registry entries etc. We'll update the program by just replacing the current .app with a new one.
Create a new Update.exe for macos - most of the windows functionality is not relevant, we really only need it to swap out the .app bundles during an update.
The text was updated successfully, but these errors were encountered:
Now that Squirrel is on dotnet 6, there is no reason we can't build cross-platform binaries and consider adding support for other operating systems.
Windows arm64
There are not a lot of code changes required to support arm64 properly, most of this is just recompiling binaries. There also should not be any compatibility issues creating x64 packages on arm, or vice versa.
To support applications being deployed to arm64:
RuntimeCpu
AssemblyRuntimeInfo
to check for ARM when detecting OS machine architecture[ ] Compile(x86 binaries can be virtualised on x64 and arm64)StubExecutable.exe
,Setup.exe
,Update.exe
for arm64. (they are all x86 at the moment, technically windows on arm supports x86 emulation, so maybe we could skip this)SquirrelCli.Releasify
to check for incompatibilities between x86/x64 and ARM when building packages and store the correct machine architecture into the package metadata.[ ] Also update(not needed since we are only building x86)SquirrelCli.Releasify
to use the appropriate Setup86 or SetupArm64 (and Update86/etc...) depending on the package architecture.Update.Setup
when checking current architectureTo support compiling releases on arm64:
[ ] Compile(not needed as Squirrel.exe is now a cross-platform csq tool)Squirrel.exe
for arm64singlefilehost)macOS
I do not believe we can support building packages for macOS on windows as
codesign
andxcrun
/altool
is not available. Similar issues trying to build windows packages from MacOS, but we can use Wine to fill in some of the gaps. I will not support installing dotnet runtimes on linux/macos, so only self-contained apps will be supported.We can create universal binaries for mac that work natively for more than one operating system / cpu architecture using
lipo
, this seems to be preferred instead of having separate downloads in Apple's ecosystem. Example:We should probably bundle RID
osx.10.12-x64
andosx.11.0-arm64
at a minimum to cover off the two widely used CPU architectures.We install to
%localappdata%
on windows, the closest thing on macos is probably%userprofile%/Applications
which seems to be uncommon but used by some..app
bundle during releasify instead ofSetup.exe
Can look at https://docs.avaloniaui.net/docs/distribution-publishing/macos for some inspiration.
.app
bundle needs to be notarized..pkg
which installs the application into~/Applications
(NOT/Applications
)Utility
, make sure all the file paths, process starts, process enumeration etc have abstractions for macos.app
bundles during an update.The text was updated successfully, but these errors were encountered: