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.

Thread beginning with comment 621532
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Comment by Drumhellar
by Drumhellar on Tue 1st Dec 2015 06:53 UTC in reply to "RE[3]: Comment by Drumhellar"
Drumhellar
Member since:
2005-07-12

If those are the worst complaints you have about their transition, then I guess they pretty much nailed it, then.

I mean, keeping the system path for native apps as System32 means nothing breaks when recompiled. When Windows moved from 16-bit to 32-bit, the API changed significantly, so it was cool to rename system file paths for 32-bit software, as you had to re-write Win16 apps to be 32-bit. However, the API stayed essentially identical on the move to 64-bit - software expecting system files in C:\Windows\System32 would break when compiling it to 64-bit otherwise. SysWOW64 is where 32-bit calls to System32 get redirected. Since the 32-bit system is the non-native system, they are the ones that get redirected.

LLP64 accomplishes the same thing: Compatibility. Software can be built for either 32-bit or 64-bit mode, with no changes necessary to the source.

It makes sense, too. Compatibility with existing Windows software really is more important than easier porting from other systems.

Reply Parent Score: 2

RE[5]: Comment by Drumhellar
by chithanh on Tue 1st Dec 2015 07:25 in reply to "RE[4]: Comment by Drumhellar"
chithanh Member since:
2006-06-18

As I wrote above, these are not my biggest complaints, these are examples that illustrate nicely how Microsoft handled the transition.

By prioritizing that applications can be ported with as little modification as possible, they have now the SysWOW64 and LLP64 baggage to carry around basically forever.

Also the "no changes" argument doesn't hold. LLP64 just breaks different assumptions than LP64 for program(mer)s which came from a 32 bit world.

Reply Parent Score: 3