Hi, I would like to suggest releasing a 64 bit version as even MS Edge Chromium (and WebView2) are already 64 bit and only a few programs of legacy software remain in “Program Files (x86)” folder.
There’s the added benefit of extra security afforded by 64 bit only features, which are especially useful for software that interacts with the wild internet, parsing all kinds of html in e-mails, which can look legitimate, come from legitimate contacts, and carry software exploits, (which in the past led to the demise of Internet Explorer etc, and secured Chrome as the uncontested leader in the browser market).
Now there are interesting releases from Microsoft such as WinUI 3 and .NET Multi-platform App UI (.NET MAUI) which seem to be the way forward and will allow emClient to release from one codebase to all platforms automatically, with full security features and store integration. I hope your team can consider this scenario as plausible, even desirable. Thanks.
There is no performance advantage to running eM Client as 64bit because the dominant operations are not CPU based. Any performance limit will be because of disk and network throughput.
eM Client uses .NET so recent CPU extensions can even be used in 32bit mode applications.
Can you explain what security features are not available?
I think customers are not the right people to ask, but to clarify, when I mentioned 64 bit only features, I meant the ones only available only to Windows 64 bit editions. If Windows has a way to propagate those security features to 32 bit user programs somehow, that’s maybe enough for now, but I still believe going 64 bit is a positive step.
As far as I know the only difference is in the way the CPU handles data, but as eM Client operations are not dominantly CPU based, there is no real advantage.
Well not really, all the innovation is being done on 64 bit only, as far as I know 32 bit processor ISA is stuck in time.
Most if not all hardware/software security barriers are exclusive to 64 bit Windows OS, and not reachable by 32 bit editions of Windows.
Just ask your programmers team who build the releases.
Agreed, eM Client should be available as a 64-bit application on Windows.
eM Client on Apple devices must already be 64-bit anyway, as macOS Mojave (2018) was the last version of macOS to run 32-bit applications. From macOS Catalina (2019) onwards, 32-bit apps were no longer supported – only 64-bit apps are now supported.
On Windows there is no advantage to running an application like eM Client as 64 bit. Therefore to provide a single app compatible with all Windows versions, we only provide the application as 32 bit.
For one, the size of the 32-bit address space places practical constraints on the ASLR entropy that can be added, and therefore 64-bit applications make it more difficult for an attacker to guess a location in memory.
One of the major differences between 64-bit and 32-bit applications on Windows is the size of the virtual address space that is made available to a process. 64-bit applications whose EXE is linked with the /LARGEADDRESSAWARE flag receive 8 TB in Windows 8 (128 TB in Windows 8.1) of virtual address space whereas 32-bit applications only receive 2 GB by default. The limited amount of address space available to 32-bit applications places practical constraints on the amount of entropy that can be applied by ASLR when randomizing the location of memory mappings. Since 64-bit applications do not suffer from these limitations by default, it is possible to significantly increase the amount of entropy that is used by ASLR. The ASLR implementation in Windows 8 takes full advantage of this opportunity by enabling high degrees of entropy for 64-bit applications. Providing higher degrees of entropy can further decrease the reliability of exploits written by an attacker and also makes it less likely that an attacker will be able to correctly guess or brute force an address.
Prior to Windows 8, 64-bit executable images received the same amount of entropy that was used when randomizing 32-bit executable images (8 bits, or 1 in 256 chance of guessing correctly). The amount of entropy applied to 64-bit images has been significantly increased in most cases starting with Windows 8
Thank you for the references. Yes, that is correct.
The main reason why we distribute the application as 32-bit on Windows is to simplify distribution. We have customers running both 32-bit and 64-bit Windows versions and also ARM Windows machines. Only 32-bit applications can run in the same binary format on all of these operating systems. The alternative would be to distribute a bundle supporting all of these platforms, or three different setups that the customer would have to choose from. This would complicate the situation both for end-users and system administrators but also for us.
We evaluated different strategies for potential native support for all three platforms:
Distributing one version with support for all three platforms
(+) No need for choice for the user
(+) Easily deployable through group policies
(-) Size of the distribution (3x the size of the download, only 1/3 is actually used)
Distributing separate setup for each platform
(+) The size of the distribution stays the same
(-) Deployment through group policies to a diverse environment (mixed 32-bit, 64-bit or ARM machines) is troublesome
(-) The user has to download the correct version (heuristics on web site can help)
Install bootstrapper that would download the correct package
(+) Size of the distribution
(-) Needs to use an external tool (ie. not purely built-in Microsoft Installer)
(-) Deployment through group policies is troublesome
(-) Offline installation needs to be done differently
Unfortunately, none of the strategies work well for every possible use case and hence we would likely need to offer more than one option to even cover all the scenarios we already support today.
And as I said before, there is no visible performance penalty of running the application as 32-bit because the dominant operations are not CPU bound. They are mostly constrained by the disk and network throughput performance. Also, the reliance on the .NET platform allows us to use even recent CPU extensions in the 32-bit mode without resorting to supporting the lowest common denominator when it comes to CPU models.
For now, we have decided to keep the setup simple for the benefit of both end-users and system administrators. We may reevaluate the decision if the 32-bit Windows systems go out of support or their usage drops significantly.
On macOS the situation is different. Thanks to the tighter control of the platform hardware, Apple has dropped 32-bit support on its platforms entirely. Hence, eM Client always run as a 64-bit app.
Any progress on having a 64 bit version for Windows. We have users with huge email storage in the hundred of thousands of emails and the 32 bit seems to be the limiting performance. Also our security team is always harassing us about it.
My emClient keeps running out memory. it would be nice to have. I am importing eml files from Google Workspace, and it is taking forever breaking it up into chunks. I have like 4 TB of email to move into new email system. I have completely given up on duplicate email imports. Hopefully the sever wont import duplicate message ids.
