[Feature Request] Build Telegram for Windows on ARM64 #25266
Comments
|
Telegram cannot be ported to ARM64 just yet because some third-party dependencies are not ready (e.g. Qt ARM64 builds are still in tech preview). But ARM64EC might be a good compromise for now: Telegram runs natively and everything else stays x64.
Edit: Forget the last part. The Microsoft docs state that ARM64EC can load x64 and ARM64EC binaries but they cannot load ARM64 binaries. |
Hey Team, My name is Nicolas Ochoa, and I am an App Assure Manager with Microsoft's FastTrack Center. My team assists Microsoft customers and Independent Software Vendors (ISVs) with any application or software compatibility scenarios encountered while upgrading to our latest versions of Microsoft products. We would like to work with Telegram to prepare your applications for Windows on Arm. The App Assure team supports application compatibility for Windows 10, Windows 11, and Windows on Arm with an emphasis on collaborating with ISVs. Our goal is to help ensure your Telegram application is supported on Windows 11 and Windows on Arm. Our App Assure engineers can provide you with best practice guidelines and help remove any technical blockers encountered when developing compatible applications. These services are provided at no additional cost. Feel free to reach out to me by replying to this thread |
|
Arm64EC supports ARM64 code, but not ARM64 binaries. It works very well for partial ports in conjunction with a good linking strategy (the arm64 codebase in ARM64 and Arm64EC can be the same code essentially and ultimately you can produce Arm64X if needed to support both types from a single binary should you have any dlls which need to be able to load in both types of processes). Arm64EC is usually where I'd suggest open source projects with lots of dependencies start looking; you can get pretty great performance without having to recompile everything into Arm64. |
|
Yes please, definitely need this. |
Is that a blocker for Telegram Desktop? |
There was a need to patch few qmake files but nothing significant and overall the Qt builds for windows arm64 and works without any issues. Both with LLVM-Mingw64 and MSVC, the full source tree including the IDE, no problem at all. Though I checked it more than two years ago, I believe they didn't break it so far. P.S. For an open source project, when the dependency sources are available, depending on the prebuilt libraries seems quite weird for me. Aren't you guys supposed to have at least some good and healthy paranoia when it comes to dealing with the 3rd the party blobs? |
|
@CryptoManiac Currently the Qt arm64 builds are considered stable but the tooling isn't there yet. See https://www.qt.io/blog/qt-for-windows-on-arm
There are no official binaries yet and I don't think this project wants to built Qt itself. |
|
Well, really this project (if you're talking about TDesktop) builds (and patches) Qt itself on all platforms for ten years now. But I'm not sure about ARM build of all other dependencies, Qt is just one, on Windows there are 28 steps in dependencies-building script. Right now I don't have time to check/port building all of them to ARM and then building one more version for each release :( |
I mean, that is the point of ARM64EC: use this target for the core of TDesktop and the (third-party) dependencies can stay x86-64. Then migrate the rest iteratively one step at a time.
I would help out if I had any C++ building experience. I'm still hoping someone else will be interested in giving it a shot. 😅 |
|
In light of all the new windows ARM hardware released with the snapdragon chips, I would love to see a native version of telegram. |
|
i am sure windows arm users is far lower than linux arm users wicth is far lower than linux x86 users and preston have far higher priorities, when windows arm can run windows x86_64 binaries. |
|
As an active Windows ARM + Telegram user, I prefer the web version because ARM experience of Telegram in WIndows is awful:
On the overall Windows/ARM projections I believe this will get a lot of traction because it works at least as stable as x86 with more than acceptable performance and provides unbeatable benefits in battery, 5G connectivity, temperature and noise |
@Aokromes, What's the minimum number of people affected to address an issue? |
|
While the native WoA build is unavailable, you could use Android version. It works fine with Windows Subsystem for Android. It's an ugly crutch of course, but Android version is far more usable than Windows x86_64 version. If anything, you'll be able to make calls without spending five minutes on establishing the connection. Hope it helps. An alternative is to use Linux version with WSLg. |
It works fine as long as you won't try to make a voice or video call. Something is severely broken in the cryptographic keys negotiation code. Broken so much that I have enough time to make a tea before the connection will be established. Win 11 on Qualcomm Snapdragon 8cx Gen 3 with 16 Gb of RAM. It looks like this particular code is dependent on the instruction(s) which are very hard to emulate, resulting with the ridiculously high emulation penalties. I guess this can be worked around by invoking the unoptimized code for this particular use case but this will require modifications. The application will need to be able to detect that it's running under the emulation and use the plain C version of that function in such a case, then it will be somewhat tolerable. |
Nope, autoplay GIFs and videos are problematic too. Telegram is still the top battery consumer on my Surface Laptop 7 without making a voice or video call. |
Didn't notice any trouble with them. Works fine for me. Battery consumption is another matter, though. |
Yeah, GIFs and videos play smooth, but they consume a lot of power due to emulation running behind the scenes. That's what I meant as problematic. |
|
I have a Samsung Galaxy Book S (Snapdragon 8cx) and can't confirm any of the mentioned performance issues. Are you sure that you are running the x64 build (NOT x86)? The battery usage is very poor though judging by the Windows logs. |
|
@ssg Well, from Unigram statistics the ratio of x64 users to arm users is 16'945, meaning there is almost 17'000 people using x64 version on every person using arm version, or arm userbase is ~0.006% Given that I've EOLed support for systems under 1% of userbase when the time came it's really hard to justify spending big amount of time (working week? idk) to support native arm version for 0.006% of userbase. BTW for me this percent would be even less, because Unigram works only on modern systems, while I still have relatively big percent of users on Windows 7 (more than 4% of userbase). idk.. I'm open for the thing, but it is really hard to make (and support, and build every release) a native arm version and really low part of userbase |
|
@john-preston You would have to copy the Windows x64 pipeline, change the build target to Arm64EC and leave everything else (like x64 dependencies) as is. So that's 1-2 days max? But without proper hardware or VMs there is just no way to test it yourself. Maybe Microsoft (@NicolasOchoaMSFT) would be willing to send you a Windows Dev Kit 2023? 😄 |
|
@sungaila I'm not sure building tdesktop code Arm native and leaving dependencies x64 (like OpenSSL / FFmpeg / WebRTC) will do any good in terms of performance, I doubt that tdesktop code is the main problem here. It looks like a fully native build is needed for all this to make sense. |
|
I hope I'll be able to use Mac hardware for Windows on Arm development, that way I still need only two hardware sets to build all of supported tdesktop versions (Mac on Apple Silicon builds both x64 and Arm macOS versions, Windows on x64 builds Windows x86, Windows x64 and Linux x64 versions). |
Raspberry Pi will do. There is no need for expensive hardware to run these binaries. It's painfully slow however. One might even say that forcing someone to use windows on Raspberry Pi should be classified as a war crime. |
|
I don't want another distinct hardware, I really do hope Apple Silicon would do. I already need it for macOS builds. |
|
@john-preston You could be right, I too doubt that tdesktop is the bottleneck here. For development you can run Windows 11 on ARM via virtualization on your Mac (e.g. https://kb.parallels.com/en/125375). Windows cross-compiles to x86, x64, arm64 and arm64ec on each platform. You'd need Windows on ARM to test the binaries but not for compiling. |
|
Visual Studio Preview version with the fix just got released: https://learn.microsoft.com/en-us/visualstudio/releases/2022/release-notes-preview?tabs=preview4#17.12.0-pre.4.0 |
Awesome, one step closer! :-) |
|
Tried to build release version, got "heap exceeded" on 32 GB RAM 🤣 The media viewer still is bugged 😞 |
I was able to build the release and it's working WAY better than debug (no more UI lag). Media viewer still works for me. What is bugged about it? |
|
He said to me that it has glitches. Not very informative but I bet Parallels drivers are the cause (as he runs Windows ARM VM on macOS ARM machine to my knowledge). |
Awesome, I works! 👍 I just clicked around in some chats and opened pictures/videos for testing.
Many thanks to all those who have worked to make this possible! 😄 Now I'm waiting for the update to appear in the Microsoft Store. So far tdesktop has been published as an appx there. Hopefully there will be no problems uploading both x64 and arm64 builds. |
|
@sungaila Autoupdating wasn't tested yet, so this needs to be kept in mind. |
Tried the setup and it's working fine here! Will this be added to the runners to auto build so we can test the auto update? |
No, github has no arm64 windows runner
Runners aren't related to auto update, though. You just have to wait for a new version to test. |
I did see they are in pre-release but you're right, they haven't been released in production yet (https://github.com/actions/runner/releases) I will definitely test on a couple of my ARM laptop devices when a new version comes out |
|
Note that gh runners aren't related to auto updates nor tdesktop releases in general. |
ssg
changed the title
|
There is an official ARM64 release now! https://github.com/telegramdesktop/tdesktop/releases/tag/v5.7.2 Thank you everyone who worked on this! |
We would also like to know the official release ETA on the Microsoft Store. Please let us know if there are any plans for a release in the near future. We would appreciate any leads or information about it. |
Tested auto updates today to 5.7.3 beta and it worked without error |
|
Hey Team, first of all: Thanks for finally porting this to native Arm64. 👍 Thanks also to Qualcomm for supporting! There is a BUG: As of today, I can't use "save as". The Windows file picker Window briefly opens but immediately closes again: |
|
@Vishnu-Qualcomm Telegram Desktop 5.8.1 is available in the Microsoft Store now. It even upgrades from the x64 build to the arm64 build on its own. Neat! |
Thanks @sungaila for the info, thanks to all the contributors and maintainers! |
|
@Vishnu-Qualcomm File dialogs indeed crash, I've fixed that in code and it'll be soon in the next version. |
|
plz, for future issues open one issue for each bug, since this issue is already implemented. |
|
@john-preston |
|
@Farce002 Hi, thanks. Can we skip the call? I'm not good with calls. But the build is in Windows Store now, so well done everyone, I guess. |
|
@john-preston sure that is not a problem at all, just one last thing, about Arm64 Support Statement, is that also available for general knowledge yet? |
|
@john-preston Thank you for working with the App Assure service for your application remediation needs. We have concluded efforts on this case. As per our conversation via Github the ARM64 build for Telegram Desktop is already available in MS Store, no closure call was needed. Upon your confirmation, I will close your App Assure request by Dec. 06. Please know that I will be readily available at any point to assist you with any future app compatibility issues that may arise. Feel free to reach out to me directly to re-engage. If you would like a refresher on what our service can provide, you can email us at [email protected]. |
|
@Farce002 Thanks. |
|
Can anyone solve this too? |
and others
Is your feature request related to a problem?
Telegram runs under x64 emulation on Windows ARM devices, that causes a performance penalty especially with the CPU intensive tasks like video/GIFs, etc. With the introduction of Snapdragon X series processors, ARM64 laptops are now more prevalent.
Describe the solution you'd like
ARM64 Builds for Windows.
Describe alternatives you've considered
I've considered suffering through performance problems, I didn't like it.
The text was updated successfully, but these errors were encountered: