Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Native version for Windows on ARM64 #2318

Open
ktos opened this issue Sep 1, 2023 · 28 comments · May be fixed by #2985
Open

Native version for Windows on ARM64 #2318

ktos opened this issue Sep 1, 2023 · 28 comments · May be fixed by #2985
Labels
enhancement New feature or request keep-fresh

Comments

@ktos
Copy link
Contributor

ktos commented Sep 1, 2023

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.

@ktos ktos added the enhancement New feature or request label Sep 1, 2023
@taooceros
Copy link
Member

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
Copy link
Member

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
Copy link
Contributor Author

ktos commented Sep 7, 2023

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
Copy link
Member

jjw24 commented Sep 7, 2023

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
Copy link
Contributor Author

ktos commented Sep 10, 2023

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 ericsink/SQLitePCL.raw#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
Copy link

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 github-actions bot added the Stale label Oct 26, 2023
Copy link

github-actions bot commented Nov 2, 2023

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.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Nov 2, 2023
@taooceros taooceros reopened this Nov 2, 2023
@github-actions github-actions bot removed the Stale label Nov 3, 2023
@link6155
Copy link

link6155 commented Aug 8, 2024

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

@nanoraptor
Copy link

agreed devs should not walk on this one @taooceros

@maxnabokow
Copy link

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
Copy link
Member

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
Copy link
Member

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

Not sure whether it works

@iKineticate
Copy link

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.
image

@taooceros
Copy link
Member

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

@ktos
Copy link
Contributor Author

ktos commented Sep 22, 2024

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
Copy link
Member

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
Copy link

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
Taskmgr_Nj9MfpicOn
VrX6PWlcHF

@taooceros
Copy link
Member

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
Copy link

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
Copy link
Member

taooceros commented Sep 24, 2024

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

@taooceros
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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

@iKineticate
Copy link

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
Copy link
Member

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
Copy link
Member

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

@maxnabokow
Copy link

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
Copy link
Member

taooceros commented Oct 28, 2024

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.

@taooceros taooceros linked a pull request Oct 28, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request keep-fresh
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants