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 621549
To view parent comment, click here.
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

RE[8]: Comment by Drumhellar
by dpJudas on Tue 1st Dec 2015 09:51 in reply to "RE[7]: Comment by Drumhellar"
dpJudas Member since:
2009-12-10

Here the argument is the use of structs for on-disk formats that don't use explicit integer sizes.

His defense is that a lot of old code assumes that long = 32 bit. If you change long to 64 bit, you get problems such as when reading/writing structs. It also changes when things overflow and also performance in situations where a 32 bit integer was all you needed.

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. ;)

I'm yet to see why its a bad feature to make a few "symbolic links" on the file system and in registry and have them point to different locations depending on if its a 32 bit or 64 bit process. There is nothing "messy" about it. And its invisible to 100% of users and 99% of developers. Only exception is the "Program Files (x86)" folder.

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.

Certainly depends on which platform you're coming from. In DOS and 16 bit Windows: short = 16 bit, int = 16 bit, long = 32 bit. That is precisely the reason the structs Raymond Chen mention use a long instead of an int. They were written that long back.

Changing long to 64 bit might not have had a big impact if you came from a unix background, but any code written in the DOS/16-bit era would end up in trouble. And lots of Windows applications comes from that era and therefore a perfectly reasonable choice.

Reply Parent Score: 2

RE[9]: Comment by Drumhellar
by chithanh on Tue 1st Dec 2015 12:49 in reply to "RE[8]: Comment by Drumhellar"
chithanh Member since:
2006-06-18

There is nothing "messy" about it.

Clearly we have different ideas about what constitutes a mess. I'll leave it at that.

Reply Parent Score: 2

RE[8]: Comment by Drumhellar
by avgalen on Tue 1st Dec 2015 14:53 in reply to "RE[7]: Comment by Drumhellar"
avgalen Member since:
2010-09-23

If only "it works!" were some kind of quality measure. ;)

It is very much in the top of quality measures.
Other ways of measuring quality:
* Does it fit the oath? http://blog.cleancoder.com/uncle-bob/2015/11/18/TheProgrammersOath....
* Do the boss and product owner sign off on it?

...and the very best one:
* 10 years later, do I still think I did it correctly?

Reply Parent Score: 2