Drop 32-bit support

[FranciscoPombal]

Please provide the following information

qBittorrent version and Operating System

N/A

If on linux, libtorrent-rasterbar and Qt version

N/A

What is the problem

• Mainstream Linux distros have either dropped or are starting to drop 32-bit support completely. For example, Ubuntu as of 20.04 (the latest upcoming LTS) no longer supports any 32-bit software with the exception of the bare-minimum to keep Steam going while it transitions to 64-bit.
• macOS has dropped it completely for some time now.
• Windows 10 32-bit is still supported, but it does not make much sense to keep supporting that. Most mainstream software, including web browsers (EDIT: jumped the gun) have dropped 32-bit Windows support for some time now as well, meaning using Windows 10 32-bit is basically useless nowadays. Virtually no one uses 32-bit Windows anymore, and if they do, they almost certainly use a machine that would be capable of using 64-bit Windows anyway (I doubt any 32-bit-only machine is usable nowadays).

Supporting 32-bit is a burden in terms of toolchain support. Existing build scripts would benefit from dropping 32-bit support.

The way things are now, I think a good time to drop support would be around the 4.3.0 release, in tandem with dropping support for libtorrent RC_1_1.

What is the expected behavior

qBittorrent should drop 32-bit support.

Steps to reproduce

N/A

Extra info(if any)

When I say "32-bit" I am really referring to x86, and similarly "64-bit" actually means "amd64".

[glassez]

Many low-end computers (especially tablets) uses 32-bit Windows due to resources limitations (although they support 64-bit). Moreover there is no way to replace preinstalled Windows (at least without a severe headache).
In addition I do not see any special difficulties to have support of 32-bit builds yet.

[FranciscoPombal]

@glassez

Many low-end computers (especially tablets) uses 32-bit Windows due to resources limitations (although they support 64-bit).

Do you mean those Atom tablets? Who is running qBittorent on tablets? I don't think that's the case for the vast majority of the user base. It's not the "common use case" for qBittorrent IMO. Even in recent issues you see many people complaining that a tiny increase in row height is "too much tablet UI". Plus like you say, they are 64-bit capable anyway. It's just a matter of reinstalling a 64-bit edition of Windows, which brings us to the next point below. (Note on resource limitations: I am aware 64-bit should use a bit more memory. However in such tablets you are already so resource constrained in so many aspects I don't the extra memory usage would be the bottleneck).

Moreover there is no way to replace preinstalled Windows (at least without a severe headache).

Sorry, but I disagree. It is not that hard for Windows 7/8 and trivially easy for Windows 10, since the license is tied to the user's Microsoft account/hardware GUIDs/ among possibly other things. In Windows 10 the installer automatically validates the license when reinstalling. Plus, like I said, most mainstream software, including all modern web browsers EDIT: jumped the gun have abandoned 32-bit Windows for some time. Surely anybody using 32-bit Windows has had stronger and more compelling reasons to switch other than just qBittorrent? It's not like users are gonna complain "wtf qBittorrent is the only software that has dropped 32-bit support" if we do it now.

In addition I do not see any special difficulties to have support of 32-bit builds yet.

It's not a huge deal overall, granted. But legacy stuff has to be dropped eventually, at some point it becomes just cruft bloating the project. OS/2 support was dropped with the 4.0.0 release, IMO it's time (not exactly now, but the near future) for 32-bit.

[Kolcha]

Moreover there is no way to replace preinstalled Windows (at least without a severe headache).

Sorry, but I disagree.

problem mostly not in the license... in most cases a problem in inability to insert usual USB flash drive, just because modern devices doesn't have it. you have to buy some adapters to get USB ports (also other common ports such HDMI), and not with all such adapters boot is possible, if even possible at all. also not all devices can boot from SD card. so reinstalling WIndows may be a huge headache, especially on modern thin and cheap devices (expensive devices may cause headache too, but for other reasons)

[FranciscoPombal]

@Kolcha

problem mostly not in the license... in most cases a problem in inability to insert usual USB flash drive, just because modern devices doesn't have it. you have to buy some adapters to get USB ports (also other common ports such HDMI), and not with all such adapters boot is possible, if even possible at all. also not all devices can boot from SD card. so reinstalling WIndows may be a huge headache, especially on modern thin and cheap devices (expensive devices may cause headache too, but for other reasons)

Are there that many Windows devices without at least a USB-A port? IIRC even the shitty Atom tablets had them. The devices that still shipped with 32-bit Windows 10 predate the mass removal of ports I think. And that's still mostly a trend with macbooks, not with PCs.

[Kolcha]

@FranciscoPombal
unfortunately, this is not only macbooks trend... yes, macbooks don't have usual USB ports since ~2015, almost any other 13-14" laptops - since the end of 2017, doesn't matter cheap or expensive. there are only several models can be found with USB-A ports...
don't know what about 15"+ laptops, I'm not interested in and don't what in market now, I'm using 13" since ~2010. that's why I still use my old MacBook Pro - there is no replacement for it, it is impossible to find even something equal it, especially in case of screen. almost all 13-14" laptops has FullHD screen, this is worst situation ever, and I saw such things even in 2014, so this not an option. 4k laptops ridiculously expensive, and again, they are just "phones" - hardware is not so powerful and no usual ports. moreover, I'm almost sure even it is possible to overcome the absence of usual USB, they have a lot of "good things" based on cryptography preventing even Windows installation, Linux even is out of the scope. I saw such laptops even in 2013-2014 when Win 8 became widespread, some "unique" Windows was required for them, even clean MSDN images were unable to boot on them. and that was 400-500$ devices... also I saw pretty problematic even older (2009-2011) expensive devices... so it is hard to imagine what is going now, when cryptography is everywhere, but not where it is really required and may be useful...

but this is oftopic. sorry for such posts...

[FranciscoPombal]

@Kolcha

since the end of 2017, doesn't matter cheap or expensive. there are only several models can be found with USB-A ports...

I highly doubt any device since the end of 2017 cheap or expensive, has shipped with 32-bit Windows, making this a moot point. But feel free to correct me.

they have a lot of "good things" based on cryptography preventing even Windows installation, Linux even is out of the scope.

This was to prevent installing anything other than Windows IIRC, and since we are talking about reinstalling Windows, this is a non issue. You mention some preventing even Windows installations, though. Personally, I never heard of that, but if that was widespread, I concede the point. Microsoft really wants everyone to upgrade to 10, after all. The upgrade is free even to this day, no assistive technology stuff needed (yes, really).

Slightly off-topic, but if you are looking for a 13'-14' replacement for your macbook, look into the non-dGPU asus zenbooks - very good laptops in general and great support for Linux OOTB (i.e. good ACPI and drivers). Though unless you are in a hurry I'd wait for laptops with Ryzen 4000 series processors to start hitting the market in earnest. If you really don't want FullHD on a laptop, well, you're probably out of luck. Better hope good scaling support improves across applications :).

[CzBiX]

Low power devices are very suited for a long time running BT client. and most of the devices using 32-bit OS to save resources, or only support 32-bit OS.
Such as Raspberry pi, and low-end NAS devices with arm/Atom CPU.

[FranciscoPombal]

Low power devices are very suited for a long time running BT client. and most of the devices using 32-bit OS to save resources, or only support 32-bit OS.
Such as Raspberry pi, and low-end NAS devices with arm/Atom CPU.

Raspberry Pi has been 64-bit since the RPi 2 Model B v1.2.
The last Atoms to support only IA-32 were launched in 2010. I have 2c/4t Atom from 2008/2009 that has 64-bit support.
ARM processors in general have been 64-bit in general for a long time. Whether or not those that only support 32-bit are still somehow usable today, I honestly don't know.

Out of all these cases, I'd speculate the only one that has a remotely significant number of users would be the RPi case. But even then I doubt very many people are still using pre-RPi 3 to torrent; it's just too under-powered in many ways. In fact, even the RPi 3 is very inadequate, because of the famous shared USB2/Ethernet bus, and the amount of RAM also limits it to a low number of torrents. The RPi only started becoming decent for torrenting with the 4th revision. And that's all assuming an SD card is not being used as the storage medium... In short, it's useful for a fun little experiment, not much else. Can it torrent? Absolutely, why not? It's like a regular computer. Is it a good idea? No, unless you have at least an RPi4 2 GiB RAM edition + external drive. Source: own both RPi 3 and RPi 4.

But one thing is for sure, none of these devices is running Windows, or at least they shouldn't be running Windows, because if so they are truly unusable.

[FranciscoPombal]

Hmm, actually the situation with the RPis is worse than I thought. Official 64-bit Raspbian images are not yet available, and I realize that's what most RPi users use. Just the RPi Foundation dragging their feet with essential stuff as always.

Maybe the scope of this request could be limited to dropping 32-bit support for Windows.

[Chocobo1]

Supporting 32-bit is a burden in terms of toolchain support. Existing build scripts would benefit from dropping 32-bit support.

Building 32-bit qbt is almost the same as building 64-bit qbt. I mean we do not go the extra mile to support 32-bit (please correct me if I'm wrong).
Moreover, the burden of packaging official releases doesn't fall on to your shoulders, I don't get why you are feeling the burden and want to lessen it quickly.

The way things are now, I think a good time to drop support would be around the 4.3.0 release, in tandem with dropping support for libtorrent RC_1_1.

I would say we support 32-bit until either it is a real burden (build scripts doesn't count) or when our libraries/toolchains drop the support, or when the project maintainer gets tired of it. It would be pure idiotic and selfish to limit our user base only to satisfy subjective feelings, even if the user base is a small/diminishing one.

[Chocobo1]

Windows 10 32-bit is still supported, but it does not make much sense to keep supporting that.

Furthermore, look at the download numbers here:
https://sourceforge.net/projects/qbittorrent/files/qbittorrent-win32/qbittorrent-4.2.3/
Basically you're advocating we dump ~22% of our user base on Windows (at most). Good thinking! /s

[rafi-d]

Funny, seeing uTorrent going the exact opposite direction, keeping only a x86/32 bit release, and not bothering with a 64 bit version at all...

[FranciscoPombal]

@Chocobo1

Building 32-bit qbt is almost the same as building 64-bit qbt. I mean we do not go the extra mile to support 32-bit (please correct me if I'm wrong).
Moreover, the burden of packaging official releases doesn't fall on to your shoulders, I don't get why you are feeling the burden and want to lessen it quickly.

I would say we support 32-bit until either it is a real burden (build scripts doesn't count) or when our libraries/toolchains drop the support, or when the project maintainer gets tired of it.
It would be pure idiotic and selfish to limit our user base only to satisfy subjective feelings, even if the user base is a small/diminishing one.

There is no "arbitrary selfish motivation" here. Build scripts do count. One of the major pain points I have identified with qBittorrent as I got more involved is the build system:

• We are in a limbo of supporting 2 different build systems
• The efforts are split between both, so they both suffer from problems
  • As an example for autotools: try makeing the regular version and then makeing the nox version without make cleaning in between.
  • Example for CMake can't install the systemd
  • Both: many small workarounds here and there that are probably not needed anymore and increase complexity and cognitive overhead of looking at them
• Build process is too complex on Windows, hence my efforts in the other thread about GH Actions builds/CI.
• As a result, it is difficult to get nightly builds out for testing, and telling Windows users, the majority of the user base, to compile from source is not really an option.
• Freeing up the maintainer from such a burden would free up more time for more important things. No more worrying about discrepancies between 32 and 64 bit builds, for instance.

Right now, one of the main obstacles preventing us from delivering a better product to the userbase is precisely the build system. Anything done in the way of simplifying it can contribute to a better project overall. I'll say again that if we had been providing official nightly builds, the 4.2.2 debacle could have been avoided. Instead, we are subject to the time that the maintainer and some users can (or can't) invest into manually putting together a test release and posting it in a buried comment in some random thread.

Right now I am attempting to alleviate the problem with the GH Actions builds. But I still think that fully committing to (modern) CMake as the only build system is the real, long-term solution to provide the true levels of flexibility needed. Though that doesn't seem to be a priority for anybody else...

Furthermore, look at the download numbers here:
https://sourceforge.net/projects/qbittorrent/files/qbittorrent-win32/qbittorrent-4.2.3/
Basically you're advocating we dump ~22% of our user base on Windows (at most). Good thinking! /s

You assume all of these 32-bit downloads come from people who really actually need 32-bits. This is most likely an incorrect assumption because:

• Users often just click on the first link, which happens to be for the 32-bit version (in sourceforge and fosshub alike).
• Less tech-savvy users are "scared" of x64 - they don't know what it is or does. "WIndows x64? I have Windows 10" or "Windows 10 x64? I have the Home edition". Or they think it's a beta version or something
• Users go out of their way to download the 32-bit version, if available, due to old habits/unfounded beliefs/superstitions that 32-bit "works better" (probably a scar from the early XP/Vista 64-bit days)
• For years it was standard practice to write something like "Grab this one if you're unsure which one to get" next to the 32-bit installer in popular Windows software websites
• For years many software products defaulted to 32-bit with a tiny link for x64 below; furthermore, when mainstream software (such as browsers) transitioned over to 64-bit, it stopped being relevant to mention that; so older/less tech-savvy users just assume 64-bit is something in the past they don't need.

~Think about it, do you really think 22% of our user base is on 32-bit -only Windows systems? As an example, you think mainstream browsers would've dropped 32-bit support if that meant dropping 22% of the user base? They did it way before us, and the user base of a web browser is much larger, diverse, and includes quite literally tech-illiterate people (if you use torrents, at the very least you're not completely tech-illiterate). Web browsers are some of the pieces of software with the biggest incentive to keep legacy compatibility and it wasn't a problem for them, EDIT: jumped the gun so it won't be for us. qBittorrent is not a museum piece, it has to move on.

I can't give you hard numbers. But I've pointed the ones you gave me could be meaningless in practice. My intuition tells me this is really a hill I would be willing to die on - if we suddenly dropped 32-bit (Windows) support, it would only affect a few dozen Windows users at most; the rest are actually using 64-bit systems anyway and won't even notice a difference.

Bonus: your comments are quite ironic coming from one of the people who were responsible for- and then defended- the decision to drop official support for Ubuntu 16.04 a full 1.5 years before its EOL. Not that I would flat-out disagree under all circumstances. But I think you see how inconsistent this kind of decision was with the support policies for everything else/general attitude towards dropping legacy stuff.

[glassez]

mainstream browsers

Just for fun... what browsers you're talking about?

[FranciscoPombal]

@glassez @Chocobo1

mainstream browsers

Just for fun... what browsers you're talking about?

I had Chrome and Firefox in mind... BUT I see now that I misread/misunderstood. Apologies for that. They are not offering 32-bit versions for 64-bit machines on their website anymore by default, and they have dropped 32-bit macOS support, but that is quite different than dropping 32-bit Windows support.

Thanks for the correction. I have corrected the information in my posts above. However, all of my other points stand on their own.

[xavier2k6]

If windows 10 compilation was branched off/compiled seperately in the interim (since windows 7/8/8.1/linux 18.04/macOS 10.13 (High Sierra) are still going to be maintained for the foreseeable future) - it would allow the use of more refined NTDDI_VERSION to allow the use of Qt 6.0 officially & it's minimum system requirements etc.

EDIT:

The drop of certain OS support doesn't have to happen in next release but steps should be taken now for future planning....notify users etc. like below! (hence also why I suggest branching off windows 10)

Monday November 19th 2018 - qBittorrent v4.1.4 release
There will be 1-2 more releases in the 4.1.x series. After that we will switch to 4.2.x. The 4.2.x series will drop support for versions of Windows before Windows 7.

Just over a year later:

Tuesday December 3rd 2019 - qBittorrent v4.2.0 release
WINDOWS: Drop support for < Windows 7
MACOS: Drop support for < macOS 10.10 (Yosemite)

[FranciscoPombal]

We are already in the middle of switching from libtorrent 1.2.x to 2.x. I don't think it's wise to introduce many more combinations.

Here is my suggestion: after the 4.3.x series is wrapped up (possibly with 4.3.2), which will most likely happen early next year, we immediately drop support in master for:

• Windows < 10 1809, and 32-bit Windows
• Ubuntu 18.04 and other distros that ship Qt < 5.12 LTS
• macOS < 10.14

This will make development easier while we go through these 2 critical transitions (Qt and libtorrent).

About Linux version support: raising the minimum required Qt version to Qt 5.12 will cut off Ubuntu 18.04, but this is reasonable since 16.04 also had a ~ 3 year run, so it is not unprecedented, even though 18.04 will still be supported by Canonical 2 more years (however, one must also bear in mind that only some packages get the full 5 years; technically speaking, even some Qt packages will be unsupported after 3 years from release). The >=4.3.1/libtorrent 1.2.11 release already provides a good experience for Ubuntu 18.04 users, it's not a bad release to stay on until they upgrade their systems.

The reasoning behind setting the minimum supported version of only 5.12 LTS (and not, say, 5.15 LTS) on Linux is primarily due to Ubuntu 20.04 - the majority of Linux users use it or some flavor of it (I'm sure there are good sources around the web backing this up), and the vast majority of Ubuntu users use LTS releases (Canonical actually has hard numbers backing this up). I don't think it is reasonable to cut all of those users off. The best we can hope for is an SRU for Qt 5.15 or 6.x on Ubuntu 20.04, but I'd say that is unlikely to happen for Qt. Alternatively, it is possible that Qt6 is made available on Ubuntu 20.04 not as a replacement for the existing Qt5.12 packages, but as an addition to them. This would be ideal, but I'm not sure how likely it is to happen.

The minimum supported Qt version on Linux should then be revised by 2022-04, when the new Ubuntu LTS release comes out. By that time, if everything goes well with using 6.x for the other OSes as well, we might be able to drop Qt 5.x entirely at last.

[FranciscoPombal]

Forgot to add, but I'll post separately because this is important:

Since building with Qt 5.x will still be possible for a while due to supporting Ubuntu LTS and other distros, we could provide official but unsupported, binaries for 32-bit Windows/Windows < 10 1809 built with Qt 5 >=5.15. It's an "escape hatch" for users on obsolete systems until the full migration to Qt6 is completed.

We could do the same for macOS, but I don't think it's needed; the user base is small, Apple actually forces users to upgrade OS versions more harshly, and the users are not as likely to zealously stick to an obsolete version anyway. But hey, if there is demand, why not? Maybe a forum poll or something would be in order to gauge interest in such official unsupported builds for macOS.

EDIT: This is trivial to accomplish if we have a fully automated release build pipeline sorted out.

[xavier2k6]

Since building with Qt 5.x will still be possible for a while due to supporting Ubuntu LTS and other distros, we could provide official but unsupported, binaries for 32-bit Windows/Windows < 10 1809 built with Qt 5.15.x LTS.

There won't be any more official updates for Qt 5.15 (well not for open source anyway!)

Next Qt5 version (for open source) will be Qt 5.16

So, do all future versions take a step back to Qt 5.12.x??? Qt_5.12_release_plan (Don't know the impact of that (re-introduce fixed bugs etc, less/more maintenance?)

some decisions to be made alright....going forward.

will most likely happen early next year, we immediately drop support in master for:

Windows < 10 1809, and 32-bit Windows
Ubuntu 18.04 and other distros that ship Qt < 5.12 LTS
macOS < 10.14

Perhaps it could be done when Qt 6.1 is released?!

For ref:
Qt 6.1 release plan

[FranciscoPombal]

@xavier2k6

So, do all future versions take a step back to Qt 5.12.x??? Qt_5.12_release_plan (Don't know the impact of that (re-introduce fixed bugs etc, less/more maintenance?)

No, you misunderstood me. Minimum requirement to build on Linux is raised to Qt 5.12. Windows and macOS are still built with whatever latest release it is possible to build with.

There won't be any more official updates for Qt 5.15 (well not for open source anyway!)

Oh, right, I have edited my comment to reflect this.

[Mazino-Urek]

I support @FranciscoPombal 100% on this.
There can be a final 32 bit version which will be available on website to download.
It is not like torrent users need to have the latest software to share file anyway.

[FranciscoPombal]

It is not like torrent users need to have the latest software to share file anyway.

I mean, everyone should use the latest possible version on reasonable platforms, I just don't think that FOSS projects such as qBittorrent should bend over backwards to continue supporting users that chose to stay on obsolete platforms for more often than not bullshit reasons. If the user makes this choice, then they shouldn't be surprised they get stuck on an older version of the software as well. And yes, like you say, due the magic of stable, interoperable protocols, these users will still be able to use the older versions on their obsolete platforms for a long time.

[Ryrynz]

How would anyone know there are any real issues with Qt 6 if it isn't built with it? All you'd be doing is delaying it in the hope that some broken perceived broken functionality is fixed, that may not actually be found until qBittorrent is actually built with it? Better to get it sorted now and if there are any issues get them reported so they're fixed ASAP rather than waiting for some magical "fix all" 6.1 release that may not even fix issues that might have been found if built with Qt 6 earlier.

[xavier2k6]

How would anyone know there are any real issues with Qt 6 if it isn't built with it?

There are already issues found when compiling & work ongoing to rectify.

• I usually build test versions with the "latest & greatest" dependencies/libraries for purposes like this (even sometimes when they are still beta/rc)

Qt 6 introduce numerous incompatible changes that I don't think we will able to support both Qt5 & Qt6 at the same time.

So, not as easy as one might think.

Point of note:
Qt 6.1 is scheduled for release in April 2021
Qt 6.2 LTS is scheduled for release in September 2021 (first long term supported version in the Qt 6 series)

[Ryrynz]

There are already issues found when compiling & work ongoing to rectify.

On the Qt side or qBittorrent side or maybe both?

April isn't all that far off anyway.. If problems building against Qt 6 are for the most part instantly obvious then maybe it is best to wait for 6.1. Is Qt usually that bad? I just get the impression not much testing is done based on what I've read about with previous releases breaking things.

[FranciscoPombal]

@Ryrynz

Better to get it sorted now and if there are any issues get them reported so they're fixed ASAP rather than waiting for some magical "fix all"

Actually, there are issues that can be fixed simply by building with a more up-to-data Qt, for example DPI/scaling issues, because it's the Qt code that interacts with the OS that has to be fixed, and there is no real way that qBittorrent can bypass that - at least not with some tremendously ugly and complex hack that is 100% not worth the effort on our side - might as well help fix Qt itself.

Anyway, right now qBittorrent can't be built with Qt6 at all, so it doesn't matter anyway. Extensive code changes are needed first.

Is Qt usually that bad? I just get the impression not much testing is done based on what I've read about with previous releases breaking things.

Some instances were due to Qt regressions (I recall an RSS issue with builds with Qt 5.13.x), others simply because not enough testing is done, yes, and sometimes releases are done too suddenly without any meaningful community call for testing (4.3.0/4.3.0.1, though admittedly in that case there was a lot of pressure for a releas). The GitHub Actions builds alleviate this situation somewhat - at least now there are Windows builds for every recent commit are readily available - previously getting testing builds to the hands of users was a manual process with no guarantees (Windows users are our largest demographic, and it's also the worst platform for compiling from source).

[xavier2k6]

The next iteration of Visual Studio (2022) will be 64-bit

• It will drop support of 32-bit Operating Systems
• It will drop support of Windows 7/8/8.1
• It will drop support of ARM Operating Systems
• Raises Windows 10 minimum Build/Version (>=1909)

ref.:
https://docs.microsoft.com/en-gb/visualstudio/releases/2022/system-requirements#visual-studio-2022-system-requirements

[Ryrynz]

Can't imagine qBittorrent moving to VS 2022 until more than a few years later then. Maybe qBittorrent 6?

If it was me as soon as VS 2022 rolled out I'd just compile with it, ignore the complaints and give people a reason to upgrade unapologetically haha. Can't be more than a few percent of qbittorrent users either on 32bit systems or using Windows 10 1903 and earlier now. By 2022 I expect over 80% of Windows 10 users will be on 1909 or above and over 80% of the desktop userbase will be on Windows 10 as well, personally I think that's a good enough cut off point as far as support goes.

[xavier2k6]

@Ryrynz Our windows CI (AppVeyor/GitHub Actions) are now both using Visual Studio 2019.....no doubt when Visual Studio 2022 becomes available on these systems - we will migrate.

GitHub Actions have said that they will have Visual Studio 2022 running on Windows Server 2022 when it is released/ready.

Visual Studio 2022 Preview 1 is available now to download & can be used to compile (for test purposes)

We will be looking into Minimum OS Support etc closer to releasing qBittorrent with Qt 6.x Series (WIP)

[PizzaProgram]

At least add a direct link to the last known 32bit downloadable to the download page please.
Searched 20 minutes long... :-(

https://www.fosshub.com/qBittorrent-old.html?dwl=qbittorrent_4.4.5_setup.exe

OFF ... anyway, congratulation for those forced to drop 32bit support!
Well done forcing users to drop their old PCs. Let's accelerate this...