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 621530
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: Comment by Drumhellar
by chithanh on Tue 1st Dec 2015 06:41 UTC in reply to "RE[4]: Comment by Drumhellar"
chithanh
Member since:
2006-06-18

If this is your biggest complaint, the name of a directory, then I'd say their 64 bit support works pretty well.

It is not the biggest complaint, it just exemplifies how they handled the transition.
Edit: and not to have a misunderstanding, it is not the name of the directory I am complaining about. It is the ugly and complex filesystem and registry redirection mechanism they built around it. Find a simplified description here:
https://www.sepago.com/blog/2008/04/20/windows-x64-all-the-same-yet-...

Yes, that probably sucks a little bit for those writing compilers. Still, that's a design decision and not "a mess".

In addition, that breaks assumptions many application programmers made, because a long can no longer hold a pointer or an array index. I know it is a bad assumption to make because (u)intptr_t and size_t should be used, but then again it was a popular assumption. In addition to the fact that Microsoft compilers refused for a long time to support e.g. C99 printf modifier for size_t.

Edited 2015-12-01 06:51 UTC

Reply Parent Score: 4

RE[6]: Comment by Drumhellar
by dpJudas on Tue 1st Dec 2015 07:53 in reply to "RE[5]: Comment by Drumhellar"
dpJudas Member since:
2009-12-10

It is not the biggest complaint, it just exemplifies how they handled the transition.

Yes, they went for minimizing risk and thus maximize compatibility. The System32 folder is not meant to be accessed directly by applications. But because they themselves had a vast amount of legacy code hanging around they opted for not breaking anything. I fail to see how that's bad for a folder nobody is supposed to even look at (both from a user AND a developer perspective).

It is the ugly and complex filesystem and registry redirection mechanism they built around it.

All in the name of compatibility. And it is completely transparent to 99% of all applications. I suppose you prefer the way Linux did it when they switched the default locale to UTF-8: breaking less popular applications left and right. Sure you could say it makes Linux less messy today, but I sure was annoyed when my editor (joe) broke for a couple of releases of Debian.

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!

In addition, that breaks assumptions many application programmers made, because a long can no longer hold a pointer or an array index. I know it is a bad assumption to make because (u)intptr_t and size_t should be used, but then again it was a popular assumption.

Changing 'long' to 64 bit might help on the applications you refer to, but would be devastating to code bases that relied on them being 32 bit. An assumption just as popular.

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.

Reply Parent Score: 2

RE[7]: Comment by Drumhellar
by chithanh on Tue 1st Dec 2015 09:28 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[7]: Comment by Drumhellar
by Alfman on Tue 1st Dec 2015 14:37 in reply to "RE[6]: Comment by Drumhellar"
Alfman Member since:
2011-01-28

dpJudas,

Yes, they went for minimizing risk and thus maximize compatibility. The System32 folder is not meant to be accessed directly by applications. But because they themselves had a vast amount of legacy code hanging around they opted for not breaking anything. I fail to see how that's bad for a folder nobody is supposed to even look at (both from a user AND a developer perspective).


Short answer: tell that to the hosts file ;)

Long answer: The main issue I have with the scheme is that the mangling could have been avoided entirely if MS hadn't decided to place 64bit resources in (previously) 32bit namespaces. This created the incompatibility that mangling was subsequently required to address.

c:\Program Files -> 64bit programs, 64 bit programs and dlls could have gone anywhere
c:\Program Files (86) -> 32bit programs, require mangling for backwards compatibility
C:\Windows\System32 -> 64 bit DLLs
c:\Windows\SysWOW64 -> 32 bit DLLs, require mangling

I'm hard pressed to think of any justification for the mangled scheme, which is confusing, complex, and unnecessary. In hindsight, it should have been grounded. Here is what MS should have done without the namespace over-engineering we ended up with...

c:\Program Files -> 32bit programs, no incompatibility at all
c:\Program Files (64) -> 64bit programs, no preexisting 64bit programs to be incompatible with
C:\Windows\System32 -> 32 bit DLLs
c:\Windows\System64 -> 64 bit DLLs


I actually don't think mangling was deliberately planned, instead it was probably the natural result of an incremental development strategy whereby developers would first produce a working 64bit windows and only then would they address the need to "add 32bit". Instead of going back and fixing the 64bit stuff they'd just add a new hack for the 32bit stuff being added to keep it from breaking on the 64bit OS. So it could have been avoided with a bit more planning.


An earlier thread on this topic:
http://www.osnews.com/thread?616089

Edited 2015-12-01 14:49 UTC

Reply Parent Score: 4