I was searching for Chrome 64 bit version, and I found that the central argument to not releasing that version is: "now, it wouldn't really give much benefits for the effort that would imply". (Or something similar).
My simple question is: It isn't most of the work of a 64 bit version done by the compiler?. In my head the '64 bit version' it's just the same logic, using 64bit CPU registers.
Obviously I'm missing some important points in migrating a 32 bit version of some software to a 64 bit version, and I'd like to know the central ones to investigate a bit. I'd suspect that the main problem is third-parties plugins/extensions or similar, but I'm not really sure.
Thanks in advance.
'msvs_settings': {
'VCCLCompilerTool': {
'WarningLevel': '3',
'WarnAsError': 'false', # TODO(maruel): Enable it.
'Detect64BitPortabilityProblems': 'false', <== here
},
},
From the chromium/src/build/common.gpyi file that I downloaded a while ago. Just a hint that the codebase isn't 64-bit clean, not entirely a slamdunk since the option got deprecated in VS2008. But yes, the codebase for Chromium is humongous and there's a lot of code that wasn't written by Google engineers. There are bound to be places where it loads a size_t or ptrdiff_t into an int or long. With the additional headache of Windows and Linux using different type mappings.
That kind of trouble isn't hard to find, just compile it with a 64-bit compiler and see what hits the fan. The comment is otherwise accurate, there isn't any real benefit to baking it in 64-bits as far as the stand-alone browser is concerned. Chrome.exe doesn't consume a lot of VM, having separate processes for the pages in each tab helps a lot. Embedding a browser is a different story, IE was frequently embedded because it is so simple to do so they were pretty forced to provide a 64-bit version of it. If you embed, say, CEF then you've got a fairly big problem right now.