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.'"

9 of 288 comments (clear)

  1. Re:the core not even running under mac? by pizzach · · Score: 4, Informative

    Likely because they added some personal customizations to Webkit like HTML 5 tweaks/additions to Webkit. Also, if JavaScript is considered part of the core, that is likely a reason also. Chrome's implementation of JavaScript is totally different than the one used in Safari.

    --
    Once you start despising the jerks, you become one.
  2. Not open source! by emiraga · · Score: 5, Informative

    There are parts of Google Chrome that are shipped closed source. For starters: GoogleUpdate and RLZ.DLL.

  3. Re:What I don't get... by FooBarWidget · · Score: 4, Informative

    "After all, it's not like all 3 platforms would be completely alien in the backend -- they are POSIX compliant."

    Uh, sorry? Since when is Windows POSIX compliant? Windows seems to be the only major modern OS in existence that's not POSIX compliant.

    I know that Windows provides some POSIX support, but it's broken and non-compliant in various ways. For example fork() is not supported.

  4. Portability between architectures by chrysalis · · Score: 4, Informative

    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}}
    1. Re:Portability between architectures by evilNomad · · Score: 5, Informative

      It isn't designed just to work on those, they just haven't done others yet. When building a VM it is bad to start out having to support 10 different architectures as it requires you to test them all for every little change you do. It also requires that all developers know these architectures very well if they are to do proper changes.

      Besides V8 is probably the most portable thing there is in Chrome, it already works on Linux, OS X and Windows, and they provided two different architectures, making it much easier to do a 3rd and a 4th for anyone who should wish to do so.

      How do i know this? Because Lars Bak who leads the V8 team happens to be teaching my VM course, and a guy asked that specific question.

  5. Re:What I don't get... by pthisis · · Score: 4, Informative

    I know that Windows provides some POSIX support, but it's broken and non-compliant in various ways. For example fork() is not supported.

    Not true.

    Microsoft Windows Internals, 4th. Ed (Russinovich & Solomon), p. 60:

    Because POSIX.1 compliance was a mandatory goal for Windows, the operating system was designed to ensure that the required base system support was present to allow for the implementation of a POSIX.1 subsystem (such as the fork function, which is implemented in the Windows executive, and the support for hard file links in the Windows file system).

    And to head off the next common incorrect belief, p.394:

    The POSIX subsystem takes advantage of copy-on-write to implement the fork function. Typically, when a UNIX application calls the fork function to create another process, the first thing that the new process does is call the exec function to reinitialize the address space with an executable program. Instead of copying the entire address space on fork, the new process shares the pages in the parent process by marking them copy-on-write.

    The POSIX subsystem blows for a host of reasons (you can't access most normal Win32 functionality, at least not easily), but it's got fork.

    --
    rage, rage against the dying of the light
  6. Re:What I don't get... by TheRaven64 · · Score: 4, Informative

    Have you ever used a Qt application on OS X? They stick out like a sore thumb. I think they've possibly fixed it in later versions, but until recently even trivial things like the keyboard shortcuts for skipping forwards and backwards one word in a text field were different from every other OS X application. The menus usually have a different structure, the preferences panels are typically horrendous, the services menu doesn't work correctly - they're so frustrating to use that they're typically not worth the bother.

    --
    I am TheRaven on Soylent News
  7. Re:What I don't get... by TheRaven64 · · Score: 5, Informative

    Do you mean to say that OS-X breaks convention by using non-standard keyboard shortcuts?

    In OS X, option-left and option-right skip one word to the left or right respectively. This has been the case since the first release of MacOS in 1984. Windows did not exist then, and there were no standards in early X11 toolkits (there still aren't - in 2005 I was using an X11 desktop and had four applications open with different shortcuts in text fields - gtk, tk, Qt and XUL were all doing things subtly differently). Windows standardised on control-left/right, because PCs didn't have an option key and alt was used for the menu (because PCs didn't have a meta key either). It's nothing to do with OS X 'innovating' and 'using non-standard shortcuts,' it's to do with Qt refusing to respect a core element of a user interface that has remained unchanged on a platform for 24 years.

    --
    I am TheRaven on Soylent News
  8. Re:What I don't get... by cecom · · Score: 5, Informative

    Let me clarify a common misconception. Windows is _NOT_ POSIX compliant for all practical intents and purpose for one simple reason: an application using the POSIX subsystem doesn't have access to the Win32 subsystem, making it completely useless.

    For example, you cannot use POSIX functions (fork, etc) and use Win32 GUI at the same time. Thus the need for solutions like Cygwin, which emulate POSIX with enormous performance cost.

    I hope this puts the Windows POSIX compatibility myth to rest forever and nobody on SlashDot will make it ever again :-)