Linked by Thom Holwerda on Tue 1st Dec 2015 00:37 UTC, submitted by Anonymous
Google

To provide the best experience for the most-used Linux versions, we will end support for Google Chrome on 32-bit Linux, Ubuntu Precise (12.04), and Debian 7 (wheezy) in early March, 2016. Chrome will continue to function on these platforms but will no longer receive updates and security fixes.

We intend to continue supporting the 32-bit build configurations on Linux to support building Chromium. If you are using Precise, we'd recommend that you to upgrade to Trusty.

The first signs of the end of 32bit are on the wall - starting with Linux. I wonder how long Google will continue to support 32bit Chrome on Windows. For some strange reason, Microsoft is still selling 32bit Windows 10.

Permalink for comment 621549
To read all comments associated with this story, please click here.
RE[7]: Comment by Drumhellar
by chithanh on Tue 1st Dec 2015 09:28 UTC in reply to "RE[6]: Comment by Drumhellar"
chithanh
Member since:
2006-06-18

I fully understand where Microsoft comes from. The existing Win32 codebase was most important to them, even more important than providing a clean start and cross-platform interoperability.

Another gem I have come across where Microsoft defends the choice of LLP64:
http://blogs.msdn.com/b/oldnewthing/archive/2005/01/31/363790.aspx
Here the argument is the use of structs for on-disk formats that don't use explicit integer sizes.

I have been running 64 bit since the Windows XP 64 bit edition, and I'm yet to have met any application fail to launch or install due to that. I call that a success!

I don't think that tylerdurden was referring to application launch failures when declaring the transition a mess. If only "it works!" were some kind of quality measure. ;)

Microsoft opted that the ones doing the worst crime (placing pointers in integers) should be the ones fixing their code. As for the array index situation, making 'long' 64 bit would not have saved the programs using 'int' for indexes.

ISO C90 specifies that size_t must represent the largest unsigned integer type supported by an implementation, historically this was the long type. So it was not a completely unreasonable assumption to make.

C90 makes no such requirement for int.

Reply Parent Score: 2