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"?
But this was news a week ago.
Macs already have one Webkit based browser, out of the box, and it simply rocks.
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
Make you wonder where the hell that so-called google's dev's firepower is gone ? I mean, that where google use to be the scariest player on the web ! is the "I'm the biggest fish in that sea and trust me we can run everything altogether" attitude was a fake afterall ?
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".
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}}
seeing Chrome on Linux and MacOS is nowhere near "right around the corner".
Still waiting on the Google Talk client for either platform, not as if other multi-protocol clients can't handle it instead, but with it existing since 2005 for Windows, one would have thought they could have at least pulled a MacOSX port out of the depths of their laboratories by now.
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.
Has anyone created a Firefox skin that looks like the Chrome interface?
I actually think that Chrome's interface is the real innovation (I use the word lightly, stick tabs at the top of the browser so a full screen browser obey's Fitt's Law isn't really that clever, but it's still very useful). Webkit is nice and all that, but the default home page is annoying for work computers (hey everyone! look at where I spend my time surfing!). It's also a very beta product, and in a year or two it will be pretty awesome. Also V8 is nice for a Javascript library you can incorporate in your own apps.
Firefox + Chrome interface + that Javascript Monkey thing + netbook/UMPC/etc on Linux is where the real win is. Chrome on Linux is a year away at least if this report is correct, so not worth bothering with.
*NM*
That is what is "scary" about the whole business of someone like Google releasing something supposedly so innovative and important like Chrome... Although Google does support Linux coding, and does use Linux and MacOS internally, and has even released SOME multiplatform stuff (like Google Earth) they have repeatedly released software that is single-platform, MS-Windows-only. The Linux and MacOS crowds certainly have reason for concern and scepticism about Chrome.
In any case, my point with the thread is: Although I do believe that EVENTUALLY Chrome will be ported to Linux and MacOS, a lot of the "damage" is done by not releasing multiplatform right from the get-go. If they want to promote choice in browsers, they should have started with choice in OS.
I think the problem with Chrome is not that it is a good or bad browser, but that it is not really filling any market gaps.
When Firefox came out, IE6 was a dinosaur, a monopoly, feature-poor browser written by a company with an absolutely atrocious security record. Suddenly, Firefox came along and it answered everyone's prayers. The plugin system allowed numerous features to be added as needed without the risk of bloat, the tabs made navigation easier.
Of course, IE7 then came out, with every new "innovation" basically being a copy of whatever made Firefox unique, but otherwise still being atrociously bad (at the school where I teach, we're bound to IE7, and I just cannot get my head around the absolutely appalling UI)
The problem is that Chrome doesn't really bring anything new, except perhaps the integration of Google Apps into the desktop. Maybe I'm missing something, and maybe I'll have to wait until Chrome gets ported over to Linux, but honestly the impetus to switch to Chrome from Firefox just isn't there as it was with the switch from IE to Firefox.
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.
When I print something out, it has all that usual crap of the page number, page title and all of that junk. Which would be fine if I could turn that header and footer stuff off - but I can't, or at least not as easily as I can with Firefox, or even Explorer. I guess I could go into the source code and futz with it, but it is easier for me to just use Firefox when I'm doing work. It is not just an aesthetic thing for myself, I'm printing out things like shipping labels and business related letters that can't have that stuff on them.
The idea that you have to construct a totally separate UI for each platform is silly. It seems like a great idea until you start actually doing it - and then you start getting buried in UI code, not to mention the usual problem of having at least one port being done in a rather lackluster way.
To be honest, developing UIs seems to be one of the most common areas that I see NIH syndrome. Devs gripe about a mostly-working "out of the box" widget set (because you still have to do an extra 20% work to optimize and use platform-specific UI approaches in some areas, and to be fair, bugs too), then strike out on their own, but within years, they're abstracting the platform bits into a cross-platform API and voila, they end up with a cross-platform UI library. Adobe, OOo, etc. could all benefit from having a single, reliable, well-maintained library if even just for dialogs. As long as it's native under the hood, it's not much work at all to grab the window handle, write some (say) CoreAnimation code, and add some Mac slickness to your app.
People just raise the bar unreasonably high on a cross-platform widget set. It's not only supposed to get your port 80% of the way there, it's supposed to auto-optimize for every platform as well. :)
I haven't been the biggest fan of Google with their recent "we know best" stance to many issues floating about, but I have been using their services and software for a long time now, and do indeed use (and somewhat enjoy) Chrome.
What truly amazes me is the insane amount of criticism they're getting for releasing a BETA. Yes, they're a publicly trading company, but would you expect these same high standards from other startup open source projects? It's been my experience that you start a project, focus on getting something working to serve as a proof of concept, you release that and show it to everyone, then you get other interested parties helping out.
If Linux or Mac support is that important to you, should you not be in there helping to achieve that goal? That's just my two bob, anyway. Cheers.
The article talks about the codebase that has been released. The Slashdotters talk about the fact the Linux/Mac ports are a long way off. Typical!
In my opinion, it is impossible to get all the advantages of open source when it isn't cross platform as well. Specially if the only platform it runs on is windows or OS/X. Well, many of the warranties that come from a piece of software being open source, really go to waste in this case. For example, continuity of the app still depends heavily on a company's good will and survival...
There are a lot of guys saying that google doesn't need to port it to Linux since they are competing with IE. Well, guess what? We probably need it to be ported, cause there are already hype victims that are staying in windows because there is no chrome for other OSes. Oh, and in case my earlier rant was not noticeable, stop calling Chrome open source, it isn't, chromium is.
Copyright infringement is "piracy" in the same way DRM is "consumer rape"
i dont give a golly god damn about chrome to be honest, i like firefox and its plugins and such. if chrome ends up able to compete on that level, then ok, id be interested. hell, id sooner browse with opera but the widgets dont satisfy me
By and large, language is a tool for concealing the truth. -- George Carlin
Google did not cofound Mozilla.
Mozilla is older than Google.
I have been interested in contributing to the linux version of chrome but there is little assistance. The linux_dev page has only cursory information. I did run the unit tests, but I find it hard to figure out where to start. Most of the code is focussed on win32. Does anybody have any experience in starting chromium development for linux. Whats the best way to go about it?
www.SourceCodeWatch.com/org
No convenient place to insert this comment in this thread, but TFA made me realize there really needs to be a group to organize a platform where people can do an investigative journalism style analysis of a program's source code. The analysis would center, not around functionality, per-se, but around how much the program respects user freedoms, such as privacy and what have you.
It might be easier for less technical people to get involved--they don't need to write code, just figure out if the program is doing something naughty.
I see this as the needed antidote for the common suggestion that people "just look at the code" if they have a suspicion about a program. I don't think many people actually look, and if they do, are the findings being posted?
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.
I can't help but think this is showing an attitude of "we have to do the work on Windows and well anywhere else someone else will do the work for us if they want the browser"
Personally the ease of converting integer to pointer is one of the top 3 design mistakes in C (which carried across to C++).
Sorry but it wasn't carried to C++.
C++ will barf "incomptible data type" errors whenever you try to convert from one type to another.
You need to go through casting to succeed this kind of assignment, and then C++ will barf warnings about truncated data, lost precision or out of bound comparison.
The difficulties is that C is designed to execute whatever conversion you can dream of (like trying to store a 64bit integer inside a byte container) with at most a warning.
That's simply the difference of design between the language (strong vs. weakly typed).
The main problem is developers abusing pointer conversion for lots of cases where this is not only dangerous and unstable but also not that much usefull.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
In C++ the situation is indeed better. But still far from perfect. I still see two problems:
1) The old style "(int*)" cast still work and is quickly typed. The "reinterpret_cast" - what I would consider "sufficient painful to type" - is only optional. And not all compiler support it - so lazy programmers draw the "compatibility joker" to not use it. And not every programmer know about it.
2) With most compilers warnings are off by default - and quite a few programmer forget about activation it. Or don't activate warnings because of all the warnings ..... there badly written written code will produce.
So there is not only the language factor but also the human factor. Not learning the newest features of there language. Not accepting the value of warnings.
The problem is scaling it up.
The system you speak about is nice for fast prototyping some small applications.
The bigger your app grows, the faster you'll encounter problems where : :-P )
- there's so much abstractions that it's hard to describe something and come up with a result that looks like the intended design (default placement of option in menus diverges between systems - and letting the abstraction level organise menu may break some idea : OpenOffice tries to groupe everything that relates to apparence into one single menu, but that would be impossible with an abstraction level that force the "page layout" under "file..." like every other single windows application. - And that's not even considering the Vista / Office 2007 tendency to organise thing in bars instead of drop-down menus)
- or the way some things are done are so much more different between systems that there are no unified abstracted way to describe it (there's a divergent trend between interrupting the user with dialog boxes and balloons on one side and using unobtrusive side bar like in FireFox or KDE4 - if things continue that way we may end up reaching a situation where communicating out-of-usage-flow information to the user will be done in ways that don't have anything in common).
- or the "pure cross-platform blending nicely in the system's trends" is so much dumbed down (to be common on all platforms) that it is inefficient because on most platform it can't benefit from that platforms' peculiar advantages. (As in being single-button oriented because of styli-driven system and Mac single-button Mice
At some point in time, you'll be bound to provide platform-specific code. (That's something that exists already on smaller proportion, like OpenOffice using system's file boxes, or FireFox providing different default skins on different platfroms to better blend in the desktop).
You're right for small-scale platforms (where, in a way, you could describe the usage-flow in a small XML file and have a platform-specific player interpret it).
But for bigscale honking suites, it's going to be harder, either you implement different UI for each platform (hard), or you create a very precise UI which looks nice in your environment but completely sticks out in a different environment (the common "this look like arse on Mac OS X / Windows" argument).
Of course, on the other hand, the unix way (small apps that do 1 thing but do it well) tend to create pressure favoring the first kind of applications, so maybe as we slowly move out of the Microsoft monolithic culture thing will be improving.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
But Knife(), Spoon() and Chair() are, right?
Of course. Chair()'s return value is a required argument for calling SteveBallmer()
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]