Slashdot Mirror
Examining Chrome's Source Code
An anonymous reader writes "Chrome is open source, and there's clearly still some work to be done on it. In this article, Neil McAllister decided to take a peek under Chrome's hood and view it through the eyes of the developers who will improve and maintain it in the coming years. It seems Google's open source browser currently has much to offer prospective hackers — provided they use Windows. Quoting: 'The Chromium site explains how to download the source code for Linux, Mac OS X, or Windows. Unfortunately, if you're eagerly awaiting a Mac version of Chrome, you shouldn't hold your breath. As the Mac OS X area of the Chromium developer site explains, "Right now, the Mac build is a work in progress that is much closer to the start than the finish." In fact, according to the latest status report, the Chrome developers have yet to get even the browser core running under Mac OS X. Rendering actual Web pages is still a long way off, to say nothing of a usable Aqua GUI. Then again, the Linux version is in arguably even worse shape.'"
How can it be? After all it's based on Webkit.
They still have a near monopoly on the entire Linux desktop market!
So they want to develop a cross-platform browser.
Why exactly is it then tied that tightly to a platform that porting it over to other platforms seems to basically mean starting all over again? After all, it's not like all 3 platforms would be completely alien in the backend -- they are POSIX compliant. Then the GUI: it's not like there aren't any cross-platform widget sets out there. But even if you want to go for individual approaches for each platform, then you still can separate functionality from the GUI.
So why again is the Mac port "closer to start than finish" (especially when reminding that Chrome is based on Webkit) and the Linux port "even worse"?
Chrome is a combination of numerous libraries and source code, from sources as diverse as Google, Microsoft, the KDE project and Apple. While this allowed them to initially put together the browser relatively rapidly, there is a lack of cohesion. This will surely lead to maintenance issues later on down the road, due to the hacks necessary to get everything to mesh.
There are enough maintainability issues with, for example, the Mozilla codebase, where they wrote most of the code themselves. It'll be far worse for Chrome.
i knew it from running chrome in wine there are just too many issues already, too many pure-windows dependencies, the code seems very windows centric. Which is real pity for google, they might as well go to kiss and make up with Ballmer so they can throw chairs together at Steve Jobs and the linux community. Also a real pity, i wonder if the so called improved javascript VM will actually ever make it in the real world... cause we REALLY REALLY need optimized javascript; not to mention optimized Flash but thats another problem... - zanfr http://www.kruhm.org/
I suppose it's good business sense to write software for the most popular platform. With around 75% of the OS hits being from Windows, it would be prudent to sink resources into a windows browser, rather than Mac or Linux.
On the other hand, Mac use is steadily climbing and climbing among young people. Young people are typically drawn to free and shiny (one might say, Chromed) things. They're also good at starting and perpetuating trends. In that light, it might make sense for Google to sink more resources into making an OS X version. It's important to not only have a good product, but to make it fashionable to use that product. Lord knows how many people are still using IE, not because they like it, but rather because they don't know there's anything faster or better out there out there.
They might as well forget about Linux though. Everybody knows that Linux users are crotchety and only really want to use wget and for really special pages, lynx. I for one can't remember the last time I used a window manager and LIKED that new fangled environment. Too many colors and flashing lights, it's like those arcades that them darn kids like to visit.
This one's tricky. You have to use imaginary numbers, like eleventeen... --Hobbes
The implementation of the sandbox in Windows is based on Windows-specific features. I suspect when they finally get it running on other platforms it will behave differenty with different levels of protection.
There are parts of Google Chrome that are shipped closed source. For starters: GoogleUpdate and RLZ.DLL.
Chrome is currently faster than Firefox at most things even when Tracemonkey is enabled. I mostly work with browser based math/finance apps, and one of the most intensive things that can be done is a numerical integral. No other browser even comes close to Chrome in terms of speed. The only drawback is that it isn't cross platform yet. From what I hear, Tracemonkey is working really well on different processors so it will be an interesting match up. Try pasting this code into JavaScript Shell from Chrome and Firefox for a comparison.
Google had the chance to show openness, platform independence, support for Open Systems principles and designs, and true independence from Microsoft control with Chrome, but lost it. If ever there were an important time to make sure of a simultaneous, multiplatform release, this would have been it. Instead, we have a typical "release for the largest platform" with weak promises of eventual support for everyone else. That isn't a good message for 2008; it doesn't match the "visionary" of what they are trying to do with Chrome.
Google irritated a large number of users that would have been most likely to try and promote Chrome and to give contributions to the code- those NOT using MS-Windows. I think it was a huge mistake they didn't hold the release until there was a reasonable set of code for all the three major platforms. Given Google's resources, I doubt it would have been all that difficult.
I have talked to many Linux and MacOS users about Chrome- most are disappointed, some extremely disappointed, and many are quite bitter, too. You can't blame them for being unhappy... and this article indicates that seeing Chrome on Linux and MacOS is nowhere near "right around the corner".
They've surrounded the tasty nugget of Mac-compatible Webkit code with a thick layer of Windows-only user-interface and thread-maintenance code.
egypt urnash minimal art.
The great irony of all of this is that Chrome (also Safari) directly owe the KDE and Qt projectÅ credit for constructing the base on which this is built. And now they are primarily targeting windows. When discussing either Safari or Chrome, I never ever even see mention of the F/OSS projectÅ to which they owe their existence. More than a pity, itÅ a crying shame. Do no evil my ass.
Worse : Chrome (especially V8) is only designed to work on ARM and i386 (32 bits) architectures. Yes, no AMD64 support, and don't even think of other architectures yet.
However, there is a lot of manpower behind the project and the developpers are very skilled. So this is not hopeless.
{{.sig}}
When MS uses the word Beta, they really mean pre-alpha. Release is Beta. If you want a release quality MS product you need to look for the discontinued tag.
Google is simpler, they got beta, beta and beta. One works, one doesn't, the other works for everyone except you and just when you became totally dependent on it, they kill the project.
Linux has Beta and RC. RC is solid but out of date so nvidia doesn't have drivers for it anymore, beta is solid but nvidia doesn't have drivers for it yet.
Solaris has only one version, more solid and sensible then a rock, it is labelled "Giving your accountant a heart attack".
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Yes it matters, because competition spurs progress. Just look at how IE stagnated until Firefox started to take market share.
It's official. Most of you are morons.
Google Talk is XMPP (an IETF standard) with a number of extensions. The extensions are all documented and submitted to via the XMPP extensions process. They don't need to write a client for your pet platform, whether it's OS X, Linux, *BSD, Haiku, or AROS, because they provide enough documentation to allow anyone to (I've done it - it's really not that hard). If the platform you use doesn't have a significant market share then it's not worth them devoting resources to support it. The difference between Google and AOL or Skype (for example) is that they actively encourage third-party tools to interoperate with their service.
I am TheRaven on Soylent News
What is it with google and their inability to write cross-platform GUI's? If nearly every OSS app can do it, why can't google?
.NET if you must, but this seemingly raw win32 nonsense is just silly.
It's a really confusing situation that in my eyes loses them serious geek points. Hell, use
As for the old argument that nothing cross-platform can look good: eclipse.
Of course, IE7 then came out, with every new "innovation" basically being a copy of whatever made Firefox unique
Hardly unique. IE7 didn't rip anything off Firefox that Opera hadn't had for years before either Firefox or IE7.
What's purple and commutes? An Abelian grape.
Because they did what one should not do: convert integers to pointers and vice versa. This only works well when the size of an an integer is the same as the size of pointer. This was true for 32 bit CPUs and programmers got used to it. (it wasn't for 8 bit and most of the 16 bit CPUs).
As the 32 bit area was so long programmers got used to it. And the fact that an int is 32 bit. In the end compiler designers where between the devil and the deep blue see. Either make int same size as a pointer 64 bit - and break existing code relying on 32 bit integer or make the in in 32 bit and break existing code relying int beeing the same size as pointer.
Personally the ease of converting integer to pointer is one of the top 3 design mistakes in C (which carried across to C++). Don't get me wrong: A system level programming language needs such a conversion. It just should not be so easy - it should be painful to use so it is not overused.