Native version for Windows on ARM64

[ktos]

Is your feature request related to a problem? Please describe.

The speed/snapiness of Flow.Launcher when running on x86/x64 emulation on my Surface Pro X2 is not great, especially in the case of settings UI.

Describe the solution you'd like

It would be great to have official native ARM64 version.

Additional context

I have been testing it for a few weeks now – I've built ARM64 variant of Flow.Launcher by myself, just changing the RuntimeIdentifier in the .pubxml to win-arm64 and compiled such a version. Everything seems to be working as for now, I have tested some plugins; if they are not compiled with native binaries in mind (just "Any CPU"), there is no problem. Node/Python plugins also seem to be working. The most important for me: the performance is greatly improved.

There is one thing which is not working OOTB, the BrowerBookmark plugin – it's depending on System.Data.SQLite, which is providing only native sqlite libraries for x86 and x64; and this is probably the most blocking feature, because it's "integral" part of the application.

One of the solutions could be to switch to EFCore-based Microsoft.Data.Sqlite, which is using SQLitePCL under the hood, providing binaries for everything under the sun (and more), and when I was browsing over the code of BrowserBookmark, theoretically, it should not be that very complex, but I've not tried yet to actually do it.

[taooceros]

Sounds reasonable. Another thing that doesn't work is the everything plugin, but since everything doesn't work on arm64 there isn't much we can do.

I can change the sqlite dependency, and let's discuss how to publish arm64 after that.

[taooceros]

Oh I remember another reason we fails to do that is the current assembly loader doesn't support loading from deps.json...Let me see whether I can fix that as well.

[ktos]

I have changed the code to Microsoft.Data.Sqlite dependency and after a minor change it builds... but I haven't tested it yet. I can open a PR in a few days if it would seem to be working.

As for Everything, I am not using it, so didn't even know it was not working on ARM64.

[jjw24]

Sounds reasonable. Another thing that doesn't work is the everything plugin, but since everything doesn't work on arm64 there isn't much we can do.

I can change the sqlite dependency, and let's discuss how to publish arm64 after that.

Need to mark Everything engine as not selectable when on arm64.

[ktos]

I have updated the Bookmarks plugin to rely on Microsoft.Data.Sqlite, which required minimal changes to the code and connection string, and after compiling for ARM64, it seems to be working (at least for my Firefox). (PR #2335)

I noticed a problem however, which probably must be taken addressed somehow: in current versions of SQLiteRawPCL there is a dependency on the build process to include the proper version (architecture) of the native e_sqlite3.dll library. So when compiling with dotnet build -r win-x64 the x64 version is copied to the output directory, while in the current approach, native libraries are always copied for all architectures and loaded dynamically, but it seems that SQLiteRawPCL is working differently now (a bit related to https://github.com/ericsink/SQLitePCL.raw/issues/389).

That means, there is a need to build this plugin actually specifying the runtime id; which is not that difficult, but I am not sure how this should be included in the build/publish process – two appveyor configs maybe, with some kind of moniker (v1.0.0-arm64?).

[github-actions[bot]]

This issue is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions[bot]]

This issue was closed because it has been stale for 7 days with no activity. If you feel this issue still needs attention please feel free to reopen.

[link6155]

I think this should be revisited since there's many new Snapdragon X laptops that have been released a few months ago.

[nanoraptor]

agreed devs should not walk on this one @taooceros

[maxnabokow]

Seems like this is one of the top ranking issues now. @taooceros @jjw24 When can we expect this Flow.Launder to work on ARM chips? Currently, this tool that's supposed to be super snappy and help me speed up actually just feels like it's slowing me down instead. :(

[taooceros]

I think we maybe can have a custom version for that. The official release channel will be have to delayed till #2616 is done....

[taooceros]

anyone wanna try the build? https://github.com/Flow-Launcher/Flow.Launcher/actions/runs/10977669596/artifacts/1962493711

Not sure whether it works

[iKineticate]

anyone wanna try the build? https://github.com/Flow-Launcher/Flow.Launcher/actions/runs/10977669596/artifacts/1962493711

Not sure whether it works

Hi, I tested the build, but after opening Flow.Launcher.exe, the software didn't seem to work. I checked Task Manager and saw Flow.Launcher appear briefly before disappearing. The architecture displayed was x86.

[taooceros]

Thanks for testing. I will try again. Maybe the first build is not in arm64?

[ktos]

Unfortunately, it seems that this build is x86-64.

E:\_t\Portable Version\Flow-Launcher-Portable\FlowLauncher\app-1.18.0>file Flow.Launcher.exe
Flow.Launcher.exe: PE32+ executable (GUI) x86-64, for MS Windows, 7 sections

I've noticed that in YAML building that is using just dotnet build --no-restore -c Release, which is AFAIK not using publish profile where the runtime identifier is defined – if I recall correctly, I was using dotnet publish -p:PublishProfile=Properties/PublishProfiles/net7.0-selfcontained.pubxml to get a ARM64 version, alternatively it should also work with dotnet build -c Release -r win-arm64.

[taooceros]

wanna try the build again? https://github.com/Flow-Launcher/Flow.Launcher/actions/runs/11000166845

Unfortunately I can't build a portable build because the runner is not in arm64, so you may want to backup the data before trying it.

[iKineticate]

Thanks for your efforts! @taooceros . I appreciate you providing the new build. I attempted the installation again, but unfortunately, it failed. However, I found the FlowLauncher folder in C:\Users\...\AppData\Local. When I ran Flow.Launcher.exe from there, it worked successfully, and I was able to test most features, which functioned correctly. The architecture shown in Task Manager is ARM64. Here are the logs from the failed installation: SquirrelSetup.zip

[taooceros]

Glad to see it works! I am not sure about the installation failure. Sometimes squirrel will just install failed, but if you try again would it persist?

I am doubting how much feature would work for this build. Some of out plugins published as win-x64 which can be problematic. Let me know if anything not works as expected!

[iKineticate]

I've tried installing Flow-Launcher-Setup.exe multiple times, but it consistently fails. While it creates the FlowLauncher folder, it doesn't create a desktop shortcut. The existing plugins in FlowLauncher work fine, and I was able to manually install plugins without any issues. However, I attempted to install a few from the store, and those failed as well. Here are the logs from the plugin installation failures: 2024-09-24.txt

Additionally, I noticed that the Explorer plugin doesn't work with Everything. It might require an extra build for the ARM version of the plugin and the ARM64 Everything SDK.

[taooceros]

Yes I manually disable everything. If you are interested, you can add everything sdk for arm64 in pr #2985.

[taooceros]

A lot of plugin seems to only publish to x64. The log is weird saying that plugins.json of explorer plugin is not found. I don't know why that can happen. Technically installing from store only download and extract the plugin, so probably the only issue is that those plugin are published for x64.

[taooceros]

I don't know about the squirrel error. It is a very old dependency that we are trying to get rid of but hasn't finished. Weird thing can happen.

[taooceros]

huh maybe the squirrel error comes from the versioning. Let's ignore that for a while

[iKineticate]

I’ve added the Everything SDK for ARM64 PR to the arm64 branch, though I'm not sure if that's the right approach. The x64 plugins should currently run fine on ARM64, but if possible, I believe compiling for ARM64 would be a better choice. Putting the Squirrel error aside, I think we’ve made significant progress in building ARM64 software.

[taooceros]

I am pretty unsure about how the emulation works. Maybe that would requires the whole application runs in x64 mode. The explorer plugin is not built for x64, but rather a generic target platform.

[taooceros]

I will check about the arm version of everything sdk. I think we need some change to the dll loading as well.

[maxnabokow]

Hi @taooceros, what's the status on this? Are we blocked by the Everything SDK? Can we make a version that just doesn't support Everything?

[taooceros]

I have made one. Haven't put everything in it yet. Check the related pull requests and the above comment? I think it works but just not perfect.