Linked by Thom Holwerda on Tue 23rd Sep 2008 15:38 UTC
Google "Since its release a few weeks ago, curious developers have been sniffing through the source code for Google's new Chrome web browser. Chrome's source is interesting for a variety of reasons: there's the new V8 JavaScript virtual machine with its boasts of near-native code performance, the WebKit rendering engine that does all the hard work of understanding and displaying web pages, and (last but not least), Chrome's secure sandbox designed to minimize the impact of any security flaws that might exist in both the browser and plugins alike. It is this secure sandbox that has piqued the curiosity of some observers, and for a reason that many may find surprising. From reading the source, it looks as though Google has reverse-engineered Windows, and that's explicitly prohibited by the Windows EULA."
Thread beginning with comment 331168
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Let the OS wars Begin!
by google_ninja on Tue 23rd Sep 2008 18:33 UTC in reply to "RE: Let the OS wars Begin!"
google_ninja
Member since:
2006-02-05

It could prove that Microsoft are deliberately hiding their best code their their own products (for want a crude description) thus hindering 3rd party programmers to better intergrate their applications with Windows (which is one of the many reasons MS have been taken to court over the years).


That is just silly. It comes down to that a supported API has to be supported. If you want to use an unsupported API that is fine, nobody is stopping you, but don't complain to anyone when it is broken in the next point release. Sun does it in java, Apple does it in OSX, Linux doesn't really do it, but the linux devs dont maintain backwards compatibility, so the point is moot.

Secondly, something like DEP is something that should be managed by the system 99% of the time. The capability exists in post XP SP1 systems to manually muck with it in those 1% of corner cases. Public facing apps that execute arbitrary code off the internet are in those cases, so they wanted to use it. Since this ability was only really exposed to the world post XP SP1 (which was primarily about fleshing out security), they had to rely on a hacky way to do it.

This is not proof that MS is "hiding its best code", it is chrome trying to utilize an obscure feature of the APIs in operating systems that came out before it was publicly supported. I would say more then anything it is a testament to their thoroughness, since most people would have just said "we dont support pre xp sp1.", as it was a major upgrade that any xp user should have.

Reply Parent Bookmark Score: 6

sbergman27 Member since:
2005-07-24

Linux doesn't really do it, but the linux devs dont maintain backwards compatibility, so the point is moot.

Linux devs don't do it *at all* because *everything* is open and visible. It is unclear exactly what you mean by "Linux". The user space API of the kernel is sacred, and programs written for 1.0 will still run against the 2.6.27 kernel. (Its only the kernel's internal API that changes.) If you are talking things like GTK. Well, GTK's backwards compatibility has been the subject of much discussion here. The GTK 3.0 plans are all about breaking some things, and its big news.

Reply Parent Bookmark Score: 5

google_ninja Member since:
2006-02-05

Yeah, all I was saying is that it is a very different world when your development team is distributed and your code is under the GPL. For commercially supported frameworks developed in a non-distributed fashion, targetted at business users who do not ever want to have to re-write code to have it function on newer versions, there is a very big difference between supported and unsupported functions.

The crux of what I was trying to say was that an unsupported function for manual DEP control on vanilla windows XP without any updates is hardly proof that MS is trying to pull one over on the world.

Reply Parent Bookmark Score: 3

RE[4]: Let the OS wars Begin!
by renhoek on Tue 23rd Sep 2008 23:01 in reply to "RE[3]: Let the OS wars Begin!"
renhoek Member since:
2007-04-29

The user space API of the kernel is sacred, and programs written for 1.0 will still run against the 2.6.27 kernel.


uhm, no sorry. linux (kernel wise) is not backwards compatible in any way. the kernel interface even changes between minor versions. this does not really matter since all drivers are included in the kernel anyway.

libc/gtk/qt/x11 and stuff like that are quite stable and properly versioned.

but more on topic. the first time i experienced windows undocumented calls was with emm, somehow windows was able to take over emm but i was not. sucks to be the one left out.

Reply Parent Bookmark Score: 0

RE[3]: Let the OS wars Begin!
by siki_miki on Tue 23rd Sep 2008 20:52 in reply to "RE[2]: Let the OS wars Begin!"
siki_miki Member since:
2006-01-17

Linux devs DO mantain backwards compatibility, and it would precisely apply in this case - they would never break sandbox of Chrome from the kernel side (except unintentionally, but when that happens, it is fixed as soon as it's discovered).

Reply Parent Bookmark Score: 2

sbergman27 Member since:
2005-07-24

they would never break sandbox of Chrome from the kernel side (except unintentionally, but when that happens, it is fixed as soon as it's discovered).

And usually results in an entertainingly colorful quote, not always suitable for mixed company, from Linus himself, to grace the kernel page of LWN's Weekly Edition. ;-)

Reply Parent Bookmark Score: 2

RE[4]: Let the OS wars Begin!
by kaiwai on Wed 24th Sep 2008 04:28 in reply to "RE[3]: Let the OS wars Begin!"
kaiwai Member since:
2005-07-06

Then obviously you've missed the NGPL vs. NTPL vs. Old Threading, where application compatible was not assured when Linux moved from the old threading model to the (which is used now) NPTL. I remember wine breaking because it relied on features based on the old fork() process idea of creating 'fake threads'.

Reply Parent Bookmark Score: 0