Bug 1313 deals with the fact that official builds do not include a 64-bit iFilter and therefore lack crucial functionality on 64-bit Windows. The bug discussion ends with Zeniko yet again linking the WhyNo64bitBuilds page as rationale for never fixing this issue. Yesterday somebody mentioned that the wiki page claims there are only two possible benefits to a 64-bit build and thus ignores the iFilter issue. I added more information about why using that page as a response to requests for a 64-bit iFilter is problematic.
These were removed from the issue comment log in an effort to squelch the facts. I've attempted to reproduce that information here.
The wiki page claims that the 64-bit build might be slower and that nobody's benchmarked it. This is simply false; lots of people have benchmarked 64-bit builds, and they're faster than the official builds. Sumatra is simply not pointer-heavy enough to make cache misses due to large pointers outweigh the benefits of x86-64. The performance advantage may not be consistently huge but it is consistently an advantage.
The wiki page claims that the significant downside to providing 64-bit builds is "user confusion." This is absurd; for four years now most applications have offered 64-bit builds, without causing major issues with user confusion. Most users, especially among those likely to seek out SumatraPDF, have become familiar with the distinction, and if the 32-bit download is set as a default, those who don't understand the distinction will download the default without being troubled by the availability of additional builds. Any marginal user confusion would be significantly less than the confusion which now exists when people find that expected features of the program are nonfunctional.
Most importantly, the wiki page claims 32-bit builds "work just as well on 64bit systems as on 32bit systems." This is plainly false, as issues 1313 and 1494 show. Important functionality is simply broken on 64-bit.
To address a couple points not on the wiki:
For some time now several different market share surveys have shown that the majority of Windows installations are now 64-bit. Among users who are likely to seek out an application like Sumatra, the proportion is surely higher. I would not be at all surprised if the proportion of those downloading SumatraPDF who have 64-bit windows were like the >=80% commonly seen in surveys of tech-aware audiences.
The developers have occasionally claimed that they just don't have the money to purchase 64-bit Windows or a 64-bit development toolchain. But people have offered to purchase these for them and they've given no response.
Krzysztof's only recent response to people asking about 64-bit seems to be trying to tell people who distribute 64-bit builds to strip the Sumatra name and logo from everything. Even organizations like Mozilla, which have a lot of registered trademarks and employ a cadre of lawyers to pursue those who violate their trademark policy, don't ask those who build unmodified source to strip the trademarks, so this seems excessive. The only way in which builds like Paehl's and Xhimoskr's dilute Sumatra's reputation is that they may dilute its growing reputation for telling people "we don't serve your kind here."