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.'"
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.
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.
Yeah, I quite agree. Knocking out a Windows only GUI application is a hell of lot easier than a cross platform one.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
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.
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
From your link
http://www.w3schools.com/browsers/browsers_os.asp
OS Platform Statistics
Windows XP is the most popular operating system. The windows family counts for over 90%:
Windows XP (73.9%) + Windows 2000 (2.4%) + Win98 (0.2%) + Windows 2003 (1.9%) + Vista (12.5%) = 90.9%
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
"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.
Same could be said for linux -- Konqueror is [one of] the first KHTML/WebKit browser[s] and WebKit runs on Linux. That should say that Linux and Mac versions should almost at the same stage and closer to the first quarter of completion.
Just because WebKit runs, doesn't mean that the browser won't.
signature is pants
Windows provides basic support for POSIX.1, but it's always been a second-class citizen and was only added to meet some US government requirement or other.
There is also SFU, or whatever they're calling it these days, but IIRC that's never been easy to integrate with the Windows GUI, and isn't available for major OSes like XP Home anyway.
To all intents and purposes, if you want to target Windows you either need to use a proprietary Microsoft API, or you need to use a compatibility layer or cross-platform library that translates to a proprietary Microsoft API; this last option is the one used by real cross-platform browsers like Firefox and Opera.
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}}
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:
And to head off the next common incorrect belief, p.394:
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
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
In places where efficient sofware, perfectly useable on old computers is sometimes preferred
http://www.en.ranking.com.ua/index.php?page=Ranks:RanksPage&stat=22|OW (who'd have thought, more than Gecko...) ;P )
http://www.en.ranking.lt/index.php?page=Ranks:RanksPage&stat=22|OW
http://www.en.ranking.pl/index.php?page=Ranks:RanksPage&stat=22|OW
http://www.en.rankings.cz/index.php?page=Ranks:RanksPage&stat=22|OW
(there are also stats for Hungary, where Opera performs similarly to "West"; though many people wouldn't consider Hungary to be in the same region, culturally at least; and I suspect culturall factors also play some role in spending habits/software choices; oh, and there's also Russia with Opera usage share comparable to Ukraine...though it's also a bit "out there"
Anyway, most interesting thing from those stats for most of you, I imagine: yes, there are places where IE is on the brink of falling below 50%
And personally I just think that it would be perfect if all four major layout engines end up each having roughly the same market share...
One that hath name thou can not otter
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
A decreasing percentage, as people move to 64bit and mac/linux increase market share.
Last i checked chrome ran fine in vista 64.
Right now its optimized for the 32bit market, that dose not mean it wont run on a 64 bit platform (even IE defaults to its 32bit version)
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 :-)
There are some pretty benchmarks on the Mozilla site that show what TraceMonkey is faster at and what it's not. What you have here is slow because TraceMonkey doesn't optimize recursion. This feature is scheduled to be implemented in Firefox 3.1b2, so the final version of 3.1 may indeed perform this benchmark faster than V8.
It is easy to find a fork() for windows, or indeed posix threads, etc.
In fact, Chrome/Chromium actually uses the Pthreads for win32 library.
Webkit doesn't include the UI layer. You need to write all the code to connect webkit to the UI to make what Webkit does visible to the user. You also need to write all the networking code to connect it to the internet. Webkit is just middleware...
Sleep your way to a whiter smile...date a dentist!