Forgot your password?
Google Businesses The Internet

Examining Chrome's Source Code 288

Posted by Soulskill
from the work-in-progress dept.
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.'"
This discussion has been archived. No new comments can be posted.

Examining Chrome's Source Code

Comments Filter:
  • What I don't get... (Score:5, Interesting)

    by Angstroem (692547) on Saturday September 13, 2008 @08:14AM (#24989427)

    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"?

  • by Anonymous Coward on Saturday September 13, 2008 @08:20AM (#24989465)

    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.

  • by dotancohen (1015143) on Saturday September 13, 2008 @08:21AM (#24989469) Homepage

    They still have a near monopoly on the entire Linux desktop market!

    Truth is, I don't really care if Chrome runs under Linux or not. What _is_ important is that there is a lot of buzz about a non-IE browser out there, and that will help Linux users no matter which browser they use. Chrome will get the attention of at least some PHBs and Frontpa^w webdevs who code IE-only websites. I have been complaining about this for years [] but now there finally is a product that they will have a hard time ignoring. Firefox was close, but was only talked about by gearheads. Even my mother-in-law asked me about Chrome. Which is too bad, as she's on Ubuntu and feels left out...

  • pffff (Score:2, Interesting)

    by zanfr (869393) on Saturday September 13, 2008 @08:24AM (#24989495)
    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 []
  • by Anonymous Coward on Saturday September 13, 2008 @08:42AM (#24989567)

    the point is that since webkit was written for and compiles on mac, what've they done to break it?

  • Tracemonkey vs. V8 (Score:5, Interesting)

    by Anik315 (585913) <anik@alphaco r . n et> on Saturday September 13, 2008 @09:00AM (#24989657)

    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.

    Math.precision=function (x, eps) { var dec = Math.pow(10, Math.floor(Math.log(1 / eps) * Math.LOG10E)); return Math.round(dec * x) / dec; };function asr(f, a, b, eps) { var c = (a + b) / 2; var h = (b - a) / 6; var fa = f(a); var fb = f(b); var fc = f(c); return Math.precision(recursive_asr(f, a, b, c, eps, h * (fa + fb + 4 * fc), fa, fb, fc), eps); };function recursive_asr(f, a, b, c, eps, sum, fa, fb, fc) { var cl = (a + c) / 2; var cr = (c + b) / 2; var h = (c - a) / 6; var fcr = f(cr); var fcl = f(cl); var left = (fa + 4 * fcl + fc) * h; var right = (fc + 4 * fcr + fb) * h; if (Math.abs(left + right - sum) <= 15 * eps) { return left + right + (left + right - sum) / 15; } return recursive_asr(f, a, c, cl, eps / 2, left, fa, fc, fcl) + recursive_asr(f, c, b, cr, eps / 2, right, fc, fb, fcr); };asr(Math.sin,0,100,1e-15);

  • by maxume (22995) on Saturday September 13, 2008 @09:02AM (#24989663)

    It uses webkit for layout, but it uses a (sort of) homegrown library for rendering: [] []

  • by sznupi (719324) on Saturday September 13, 2008 @09:06AM (#24989687) Homepage

    Unfortunatelly, Firefox wasn't close at all; it simply shifted the mindset in most places from "we support only IE" to "we support only IE and Firefox".

    It was noticeable when you use something else, like Opera... (luckily not on sites originating in my area of the world, since Opera here has from 5 to 25 percent, depending on the country; and since Firefox has over 40% in most of them, aiming sites for duopoly doesn't work)

    Seems like three major browsers is a minimum needed for them to start noticing _true_ interoperability...

  • the great irony (Score:3, Interesting)

    by Anonymous Coward on Saturday September 13, 2008 @09:19AM (#24989759)

    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.

  • by dgriff (1263092) on Saturday September 13, 2008 @10:03AM (#24990023)
    Check out SWT [] which is available for C++ as well as Java.
  • Re:Sandbox (Score:3, Interesting)

    by prestomation (583502) on Saturday September 13, 2008 @10:10AM (#24990081)

    That was a fun read.

    I mean FireFox 3.0 was touted for its "security"....In reality that browser offers even less protection / mitigation against web exploits than IE7 on Vista...

    and this

    I for one don't run FireFox 3.0 . . . I don't consider it even a worthy challenger (though it sure is fast) to IE7 let alone IE8 (due to lack of protection / mitigation technologies, the vuln counts etc.),

    Now, I'm no expert, I'm not saying he's wrong, but what I do know is that this goes against everything I've been hearing around here.

  • by skeeto (1138903) on Saturday September 13, 2008 @10:22AM (#24990175)

    And, yuck, they checked in a whole bunch of binaries. If you so a checkout of the Subversion repository (weighing in at 1.5G for the single revision checkout, 8G or so to build!) it is a huge mess. I don't think Chrome is going anywhere for a long time due to these maintainability problems you mentioned, and you won't find hackers poking around Chromium with the mess that the codebase is in. Plus, it's all tied very closely to Windows, and who wants to hack in the hacker-unfriendly Windows?

    Once I saw this, I sort-of forgot all about Chrome/Chromium. It's all hype for now.

  • by kripkenstein (913150) on Saturday September 13, 2008 @10:55AM (#24990439) Homepage

    And google is really happy with that. They don't need to target the linux market because Mozilla is already working for them here.

    The target is obviously internet explorer.

    I disagree for two reasons.

    First, we can only presume Google wants Chrome to run on Android, Google's handset OS. Which is based on Linux. So clearly Google has a direct and powerful motivation to target Linux with Chrome. (In fact a much stronger motivation than to get Chrome running on OS X - I wouldn't be surprised to see the Android/Linux version out earlier.)

    Second, one of the best ways to weaken IE is to weaken Windows - the less people running Windows, the less run IE. But if Chrome is Windows-only, that just strengthens Windows as the only platform able to run the 'best' browser ('best' at least in Google's eyes and those that like Chrome).

    In other words, every IE convert to Chrome is still locked in to Windows. Whereas Google's long-term goal is to make the OS irrelevant so long as it can access Google's web services.

  • by ypctx (1324269) on Saturday September 13, 2008 @11:55AM (#24990905)
    I'm wondering what sort of build process converts 8 GB of sources to 0.5 MB of installation exe. Must be some alien technology.
  • by Perp Atuitie (919967) on Saturday September 13, 2008 @12:01PM (#24990957)
    Maybe their goal is more "not IE" than "only Chrome". IE dominates because of habit and mindset, not any inherent benefits. If a "big-gun" company puts out a big-buzz browser, that mindset is weakened. It's the idea that MS = computer that maintains the status quo. Get people interested in venturing outside the locked "suite", and anything could happen. Marketingwise, Chrome is Google's ploy for driving people to online apps and away from the MS ones on their desktop. So, much as I'd like it to be otherwise, they'd be fools to concentrate on platforms whose users are already relying on not-MS apps. Plus, Chrome is open-source so anybody can port/modify it. What I'm wondering is, does Chrome code open up any opportunities for mozilla to enhance its products, or are the engines too incompatible to mate and reproduce?
  • by anon mouse-cow-aard (443646) on Saturday September 13, 2008 @12:06PM (#24990977) Journal

    mod-parent up. QT is the native toolkit for KDE.
    IT isn't some artificial toolkit people only use for cross platform work, wxwindows or tk. It's a real native toolkit on Linux.

    Heck, there's a windows port of KDE4.x in the works.
    I mean come on...

  • by kollivier (449524) on Saturday September 13, 2008 @12:48PM (#24991293)

    There can't be a grand unified HIG, but you're thinking about the problem backwards. Instead of trying to unify the HIGs, just have classes that abstract out the differences. For example, wxPython actually handles much of this already - the SizedControls library gives controls HIG-compliant borders and spacing on Win/Mac/GTK, while wxStdDialogButtonSizer (long name, I know ;-) will take your OK and Cancel button and make sure they appear in the right order on each platform. The platform-specific code is all built into the library - you don't need to deal with it yourself.

    The reason most cross-platform apps don't follow HIGs too well is that rather than use a library like this, they hand-code spacing, positioning, etc., usually doing the whole thing on one platform first. So then when they decide to make it cross-platform, going through and making a huge preferences window, for example, follow HIGs is a massive task.

  • by Fumus (1258966) on Saturday September 13, 2008 @12:55PM (#24991365)
    If a large enough subgroup of "the blue e takes me to the internet" group starts thinking that google=internet, then a convenient "Download chrome! Make your google experience even better." link on every search page can easily convert them.
  • by Dolda2000 (759023) <[fredrik] [at] []> on Saturday September 13, 2008 @01:20PM (#24991597) Homepage
    What a weird question to ask. WebKit is a just a library for HTML rendering. It's like asking why Windows games don't run on Linux; after all, they're written in C, known to be a cross-platform language.

    Chrome naturally consists of many other components as well, such as the actual user interface, all the glue code to actually read and write files (like the cache), doing network connections, DNS lookups, checking SSL certificates, handling its famous sandbox processes, loading plugins and all sorts of other things.

  • by Eil (82413) on Saturday September 13, 2008 @01:31PM (#24991707) Homepage Journal

    Cross-platform widget sets are always dreadful. An application developed using cross-platform widgets will, at best, work well on one platform, and more usually on no platforms. OS X and Windows have different UI philosophies, and an OS X application needs a different UI from a Windows application.

    Not true. Qt4 is widely regarded as an excellent open source toolkit and does cross-platform very very well. And since they're using WebKit for the rendering engine (based on KTHML which was designed to work with Konqueror which was written with Qt to begin with), it would have been a snap to put the two together. I'm not a Qt fanboy or anything, but it boggles the mind why one wouldn't use Qt for any open source cross-platform development.

  • by Tacvek (948259) on Saturday September 13, 2008 @01:38PM (#24991779) Journal

    TThis is somewhat odd though. The original NT Posix subsystem at the very least, was not an independent subsystem. It translated some calls into the NT kernel Native API, but for others, it translated them into Win32 System calls, leaving the POSIX subsytem dependent on the win32 susbsystem. I would find it hard to believe then that the programs could not directly call the Win32 API.

    Of course, I have the feeling that
    Interix (which is now the new windows NT Posix subsystem) has little or no real relation to the original NT 4 era POSIX subsytem. If it is a true independent subsystem, then I can definitely understand the difficulties of using a win32 API form them.

    For what it is worth, cygwin 1.7 is propping support for non-NT versions of windows, which will allow it to use NT native API's in many places. This should notably improve performance, but it is a shame that the SUA subsystem is not good enough to eliminate the need for Cygwin.

  • by Vexorian (959249) on Saturday September 13, 2008 @03:27PM (#24992525)
    I'd say that under google's perspective, the core is the Javascript VM.
  • by Sentry21 (8183) on Saturday September 13, 2008 @04:26PM (#24992941) Journal

    Less crashing, more fastyness.

    The *real* benefit would be to have a button that reloads the page using the MSHTML engine, and then intelligently remembers that for next time, so that broken shitty sites would continue to work. It could be a sort of crowdsourced, 'everyone seems to prefer this in IE' kind of approach.

    Some sort of automated compatibility would basically remove any reason to use IE over the faster, snappier, more stable Chrome.

  • by anon mouse-cow-aard (443646) on Saturday September 13, 2008 @06:19PM (#24993851) Journal

    The point is:

    1. KDE is a reference client for the QT toolkit. I consider it a very good reference. KDE is basically a really heavy work out with a lot of critical developers. If you make them happy, chances are your API is pretty solid.
    2. That the toolkit is used in a lot of other contexts (Qtopia phone environment, for example)
    3. QT has been cross-platform since the beginning. It actually pre-dates KDE. KDE was built because they saw this cute ('scuse the pun) API and decided to build the desktop environment around it.

    Compare this to TK. No-one has ever built an entire windowing environment around it. It is thought of as a scripting tool. It does not get the heavy use and thorough work out in testing that a toolkit used natively by one of the porting environments uses.

    Don't even get me started on wxwindows. That environment wants so desperately to be cross platform that it utterly sucks on all of them.

    If your implication is that because a toolkit is very heavily used in one environment it therefore must be crap for the other environments is nonsense.

    I have used/had to deal tk (in tcl and perl), as well wxwindows in smaller projects, and they frankly suck compared to QT from api elegance perspective.

  • Re:Not open source! (Score:3, Interesting)

    by emiraga (1359297) on Sunday September 14, 2008 @03:26AM (#24996695)
    There are some theories on the internet of what RLZ.DLL is doing, no one is 100% sure. The problem is that google can change RLZ.dll via GoogleUpdate at any time and it can potentially do anything.

Reference the NULL within NULL, it is the gateway to all wizardry.