[Feature Request] Build Telegram for ARM64EC target for Windows 64-bit

[ssg]

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.

Creating a new ARM64 build might be costly, but Windows applications can be compiled for ARM64EC target which is essentially x64 but with ability to directly translate to ARM so it can be transpiled to the native code on ARM platforms.

Here are the details: https://devblogs.microsoft.com/cppblog/arm64ec-support-in-visual-studio/

Describe the solution you'd like

ARM64EC enabled x64 binaries for Telegram.

Describe alternatives you've considered

I considered suffering through performance problems, I didn't like it.

Additional context

No response

[sungaila]

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.

~Also porting can be done iteratively: replace the x64 dependencies with ARM64 builds step by step. Once all third-party dependencies are updated, just change the build target from ARM64EC to ARM64.~

Edit: Forget the last part. The Microsoft docs state that ARM64EC can load x64 and ARM64EC binaries but they cannot load ARM64 binaries.

[NicolasOchoaMSFT]

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.

~Also porting can be done iteratively: replace the x64 dependencies with ARM64 builds step by step. Once all third-party dependencies are updated, just change the build target from ARM64EC to ARM64.~

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

[ChrisOfTheLewi]

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.

[khmyznikov]

Yes please, definitely need this.

[ssg]

Arm64EC supports ARM64 code, but not ARM64 binaries

Is that a blocker for Telegram Desktop?

[CryptoManiac]

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.

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?

[sungaila]

@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

Qt basically works natively on Windows on ARM. It is usable to build and run native Qt applications for your ARM64 devices but you will have to build Qt yourself. We, the Qt Company, still have some work to do to make the developer experience come up to par with the rest of our offering though.

There are no official binaries yet and I don't think this project wants to built Qt itself.

[john-preston]

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 :(

[sungaila]

But I'm not sure about ARM build of all other dependencies

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.

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 would help out if I had any C++ building experience. I'm still hoping someone else will be interested in giving it a shot. 😅

[nycevan]

In light of all the new windows ARM hardware released with the snapdragon chips, I would love to see a native version of telegram.

[Aokromes]

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.

[grandrew]

As an active Windows ARM + Telegram user, I prefer the web version because ARM experience of Telegram in WIndows is awful:

1. The UI elements are painfully slow. While app and calling technically does work, pressing every button is about a 5-second delay. And you have to press 3 buttons to make a call
2. It requires 500+ MB of RAM to just sit there while web version is less than 300. Calling on web version of telegram does not work on Edge/ARM. I believe x86 version of telegram is less than 100MB
3. Launching telegram is also about a 5-sec delay and depends on luck

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

[ssg]

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.

@Aokromes, What's the minimum number of people affected to address an issue?

[CryptoManiac]

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.

[CryptoManiac]

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.

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.

[ssg]

It works fine as long as you won't try to make a voice or video call.

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.

[CryptoManiac]

It works fine as long as you won't try to make a voice or video call.

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.

[ssg]

Didn't notice any trouble with them.

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.

[sungaila]

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.

[john-preston]

@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

[sungaila]

@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? 😄

[john-preston]

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

[john-preston]

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

[CryptoManiac]

@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? 😄

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.

[john-preston]

I don't want another distinct hardware, I really do hope Apple Silicon would do. I already need it for macOS builds.

[sungaila]

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

[CryptoManiac]

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

UTM is open source and works reasonably well. There is no GPU acceleration on Windows guests, however, but it's still more than enough for testing and development.

https://mac.getutm.app

[john-preston]

I have Windows on Arm in Parallels Studio there. I just didn't manage to go further than first dependency out of 28 that I need to compile in order to build tdesktop on Arm 😢

The cross-compiling also sucks for tdesktop because there are several code generator built and used (!) before tdesktop itself, so the resulting process is very complicated if you try to cross-compile. You need to build some libraries and codegens in host arch, then make them (the resulting binaries) available for cmake configuration run for target arch and build all those libraries and everything after the codegens run on target arch.

Apple did a really good job with their approach to two archs and universal binaries + cmake supported it, so on Apple you almost don't think about archs at all, you build all dependencies for both archs and join them in universal binary libraries (the same way on any arch you build, on Intel or Apple Silicon, you build them the same way) and then you build half of your targets (libraries and codegens) for both archs the same way on both hardware setups, and all target-arch-only libraries and tdesktop itself could be built either for both archs into universal binaries (if you need to deploy) or for a single arch only (if you need to debug and test, then you build only your host arch) -- and again, you do it the same way on any hardware, Intel or Apple Silicon. And cmake helps you all the way, giving you a way to configure wanted archs on per-target basis.

I think if Microsoft could've done something similar that would really improve the adoption of Windows on Arm for developers. I understand that's really hard thing to do so that it all works smoothly. But here we are. Another pain on Windows for that task is that some dependencies (current libvpx and ffmpeg) have no way to be built natively in development command prompt and rely on msys2 to be built for Windows, which adds complexity to building for different archs.

[CryptoManiac]

I have Windows on Arm in Parallels Studio there. I just didn't manage to go further than first dependency out of 28 that I need to compile in order to build tdesktop on Arm 😢

I've gave up on 11th or thirteen, don't remember exactly. Stumbled upon x86 inline assembly somewhere and decided to act like that exorcist priest from a movie. Some WebRTC library if I remember correctly.

[sungaila]

Thanks for the in-depth explanation, it makes it clearer which hurdles have to be overcome. Thankfully the x64 emulation is good enough imho.

[john-preston]

@CryptoManiac I got some problems right on msys2 part, if it could be overcome (building of ffmpeg and libvpx for arm native) then perhaps I could move further. The webrtc is built using my own cmake configuration from https://github.com/desktop-app/tg_owt, so I could patch it to build, I guess, because it builds fine for Arm on macOS.

[CryptoManiac]

@CryptoManiac I got some problems right on msys2 part, if it could be overcome (building of ffmpeg and libvpx for arm native) then perhaps I could move further. The webrtc is built using my own cmake configuration from https://github.com/desktop-app/tg_owt, so I could patch it to build, I guess, because it builds fine for Arm on macOS.

I did all steps manually without using this script. Got too much trouble with it. No quick hack is possible to work them around unfortunately. Some commands need the different keys for arm64, so a simple copy&paste approach won't do any good.

[NicolasOchoaMSFT]

I have Windows on Arm in Parallels Studio there. I just didn't manage to go further than first dependency out of 28 that I need to compile in order to build tdesktop on Arm 😢

The cross-compiling also sucks for tdesktop because there are several code generator built and used (!) before tdesktop itself, so the resulting process is very complicated if you try to cross-compile. You need to build some libraries and codegens in host arch, then make them (the resulting binaries) available for cmake configuration run for target arch and build all those libraries and everything after the codegens run on target arch.

Apple did a really good job with their approach to two archs and universal binaries + cmake supported it, so on Apple you almost don't think about archs at all, you build all dependencies for both archs and join them in universal binary libraries (the same way on any arch you build, on Intel or Apple Silicon, you build them the same way) and then you build half of your targets (libraries and codegens) for both archs the same way on both hardware setups, and all target-arch-only libraries and tdesktop itself could be built either for both archs into universal binaries (if you need to deploy) or for a single arch only (if you need to debug and test, then you build only your host arch) -- and again, you do it the same way on any hardware, Intel or Apple Silicon. And cmake helps you all the way, giving you a way to configure wanted archs on per-target basis.

I think if Microsoft could've done something similar that would really improve the adoption of Windows on Arm for developers. I understand that's really hard thing to do so that it all works smoothly. But here we are. Another pain on Windows for that task is that some dependencies (current libvpx and ffmpeg) have no way to be built natively in development command prompt and rely on msys2 to be built for Windows, which adds complexity to building for different archs.

@john-preston Hey John, thnak you so much for your interest and for providing your concerns for your development efforts. We are very interested in working together to make sure Telegram is supported on Windows on Arm devices. Could you please reach out to our team's email address, i will reach out directly to you so we can have a sync call with our dev engineers to go over the main approach to collaborate. Please send us an email to achelp@microsoft.com , once we receive the email i will reach out to you directly or not sure if you can reach out to me through DM . And we will be more than glad to send you a Windows Dev Kit directly to you for your development efforts.

[NicolasOchoaMSFT]

@john-preston Hi John, hope you are well. Just following up on this thread, we are ready to help and collaborate together for Telegram to be supported on Windows on Arm devices. As advised, our service is completely free of charge and we have specialized developers that will work with you at any time to provide guidance and troubleshooting if needed. We have a Dev Kit ready for shipment as well to make sure your testing and development process is as efficient as possible.

[john-preston]

@NicolasOchoaMSFT I've successfully built it 😆 Although it was very hard with dependencies.. I'll drop an email anyway.

[NicolasOchoaMSFT]

@NicolasOchoaMSFT I've successfully built it 😆 Although it was very hard with dependencies.. I'll drop an email anyway.

Hi John, hope you are well. Amazing news! we are very glad to hear these news. We have not received the email, i wil be pending on this so we can have a quick sync on how we can collaborate together as we are super excited to onboard Telegram for Windows on Arm devices. Thank you again, looking forward to talk further.

[john-preston]

Ok, everyone. So, I really went and invested significant amount of time in building all the dependencies (30 now) for ARM64 natively and built the TDesktop app itself and it was working fine (apart from the OpenGL parts fuck up due to Qt 6 which should be dealt with later), and even patched my release building scripts to support preparing / updating a Windows on ARM build, and decided to build 5.2.3 for a test, and...

Well, this is a stop for now. I have no idea, how to report that, because it is the final linking step and to reproduce that it requires building all the dependencies and the app itself, which will take a couple of hours on good hardware, I guess.

[CryptoManiac]

Ok, everyone. So, I really went and invested significant amount of time in building all the dependencies (30 now) for ARM64 natively and built the TDesktop app itself and it was working fine (apart from the OpenGL parts fuck up due to Qt 6 which should be dealt with later), and even patched my release building scripts to support preparing / updating a Windows on ARM build, and decided to build 5.2.3 for a test, and...

Well, this is a stop for now. I have no idea, how to report that, because it is the final linking step and to reproduce that it requires building all the dependencies and the app itself, which will take a couple of hours on good hardware, I guess.

This is a compiler bug. Or / and SDK issue. Got this and similar errors many times in various random scenarios on all supported platforms. Didn't really notice any pattern. Sometimes the change of compiler settings and optimization level might help. Sometimes it doesn't. Most of the times it was dealt with by replacing the affected 3rd party code with the alternatives. I'm afraid there isn't much you can do to resolve this.

[john-preston]

Yes, I understand it's a compiler bug. But usually to report and fix them you need to provide a minimal reproducible example. Here it's hard to do, minimal example is whole project.

[CryptoManiac]

Yes, I understand it's a compiler bug. But usually to report and fix them you need to provide a minimal reproducible example. Here it's hard to do, minimal example is whole project.

Well this is why the people tend to don't bother reporting it. And if you would consider the fact that most of the compiled code is proprietary then it won't be surprising why the mentioned issue seems to be persistent for at least a decade. :|

[ssg]

Well, this is a stop for now. I have no idea, how to report that,

Great that we have @NicolasOchoaMSFT here to help us.

Would you like to put your working draft on some unofficial repo so we can check it out and try to fix it too?

[pbo-linaro]

You may give a try compiling with clang-cl, instead of msvc cl (included in windows-arm64 latest llvm release: 18.1.0). It's mostly compatible (command line, ABI and dialects), so the switch should be easy. Just add bin folder to your PATH and specify -DCMAKE_CXX_COMPILER=clang-cl -DCMAKE_C_COMPILER=clang-cl to cmake command line.

Note, if you cross compile from x64, you need to add a c/c++ flag to set target: clang-cl -target aarch64-pc-windows-msvc, and you need to call it from a Visual Studio arm64 prompt to get access to system libraries/headers.

[NicolasOchoaMSFT]

@john-preston I have reached out to your email to confirm our engagement. We can report this issue you are facing to our engineers in a support ticket and we can proceed with the device shipment for further testing and debugging.

Looking forward to any follow up from your side. Thank you

[P40L0X]

@john-preston I have reached out to your email to confirm our engagement. We can report this issue you are facing to our engineers in a support ticket and we can proceed with the device shipment for further testing and debugging.

Looking forward to any follow up from your side. Thank you

If you'll be able to compile it (and I really hope so), will be possible in the future to update/upgrade all current x64 builds officially installed through MS Store to a new native ARM64 version automatically? Or people would need to uninstall current emulated one first?

Thanks, -P

[john-preston]

@P40L0X Well, I could upload a new build to the store, I have no idea how the store will update the existing installations.

[P40L0X]

@P40L0X Well, I could upload a new build to the store, I have no idea how the store will update the existing installations.

I hope we'll find out soon... 🙂

[john-preston]

@P40L0X Not really, this version (Windows build on Qt 6) requires huge amount of work regarding the media viewer, it is almost completely broken in current code :(

[P40L0X]

@P40L0X Not really, this version (Windows build on Qt 6) requires huge amount of work regarding the media viewer, it is almost completely broken in current code :(

What about shifting to the WebApp (A or K) variant as a new base for the Windows Desktop app? It seems more modern/fluid with better animations and upload speeds (but as just a web wrapper as of now, notifications and badges are a bit broken when using it at the moment)

[ilya-fedin]

@P40L0X you can download the desktop version of Web A from https://github.com/Ajaxy/telegram-tt/releases

[P40L0X]

@P40L0X you can download the desktop version of Web A from https://github.com/Ajaxy/telegram-tt/releases

Thanks, but there's no native ARM64 version for Windows either...