主题：【原创】浏览器是怎么变成操作系统的 -- 美人他爹

1.从API看能否调用是第一步，能否“正确的调用”才是关键。比如一个调用依赖于某个级别SID(安全认证级别),没有这个级别的SID告诉你这个调用的地址也没有用。从这个角度而言安全显然不是靠NAME机制。

2.安全空间是个动态变化时态，安全的空间经常有某个初始时间是不那么安全的。

正确的说法是MARC和另外一个伙计（Ben Horowitz）办的一个叫Andreessen Horowitz的VC FIRM投资了一家叫ROCKMELT的专注于开发新一代浏览器的公司。Andreessen Horowitz对该公司的具体投资数目不详，但估计要5个“米”左右。为什么?专注于手机浏览器的skyfire A B两轮的融资规模是17.8个“米”。

就是正好在看到关于新浏览器的报道时，Flash崩了，Chrome挺住啦，弹出个苦瓜脸说：这不是我的错。。。挺讽刺的。也不知道是Flash的问题，还是Chrome自己的问题。感觉Flash的ActiveX实现要比NPAPI实现稳定些，在IE里面很少遇到Flash崩溃导致IE崩溃。

【2】JavaScript还是Simple，语言未必是问题

2009年7月27日，Google发布了一种新语言，Simple (http://code.google.com/p/simple/)。Google的官方声明中说，Simple语言的宗旨，是方便人们在Google Android环境下的开发工作。但是坊间有传言，Simple的真正目标，是取代JavaScript，让浏览器在Android环境中，运行得更敏捷。坊间传言可信吗？

前文提到，很多应用软件都遵循MVC范式，M=Model=Data，V=View=UI，C=Control=Logic。在View方面，Google 最新推出的Chrome OS，与传统意义的OS，有鲜明的不同。在传统OS环境下，应用程序的UI，通常是通过编程的手段来实现。而在Chrome OS环境下，应用程序开发者不需要编写程序去实现UI，他们要做的，只是定义HTML和CSS这样的文本文件。HTML和CSS只关注UI布局和渲染的最终效果，而实现预定结果的过程，交给浏览器去自动完成。

至于Control，它的作用主要是实现用户与应用程序的交互。例如，当用户用浏览器打开某个网页，点击这个网页中的某个按钮，这个网页会发生一些相应变化。相同的按钮，不同的网页，点击按钮的后果不一定相同。这意味着，应用程序的开发者，不仅要定义UI的布局和渲染效果，而且必须有权力去编写程序，制订事件响应的处理逻辑。

如果UI的定义是通过HTML+CSS来实现的，那么事件响应的程序应该放在那里呢？最自然的方式是把程序嵌入到HTML文本文件里。JavaScript 就是这样的做法。在HTML文本文件里，嵌入JavaScript代码，当浏览器捕捉到用户触发的事件以后，浏览器找到相应的JavaScript代码，然后把代码交给JavaScript Engine去解析并运行。

1996年，Brendan Eich发明JavaScript，并使之运行于Netscape浏览器。后起的微软的IE浏览器，也追随Netscape的做法，支持JavaScript。从此，JavaScript成为浏览器必备的功能。实现MVC范式中的Control，办法很多。JavaScript的办法，优点是容易开发，但是运行速度较低，CPU和Memory消耗较高。

传统的JavaScript Engine，采用的是逐句解析的方式，来执行JavaScript代码。用这样的方式来运行篇幅很长的JavaScript代码，运行速度必然快不了。为了提高速度，最新的JavaScript Engine，大多数采用即时编译（Just-In-Time，JIT）的做法。不同于传统的逐句解析的做法，JIT整段地编译JavaScript代码，并且缓存编译结果，以避免重新编译那些先前已经编译过的代码。另外，整段编译有利于自动优化代码。

引入JIT，意味着JavaScript不再是一个传统意义的脚本语言（Script Language）。脚本语言的本质之一，是逐句解析的解释型语言，而JIT改变了这个本质，使JavaScript悄悄向编译型语言演变。 JavaScript属于哪一类语言，并不是争论的焦点。焦点在于，人们开始质疑JavaScript语言本身，以及JavaScript Engine，它们是否有必要存在。

1. 既然JavaScript最终是作为一种编译型语言被运行，那么为什么不采用预先编译的做法？所谓预先编译的做法，就是当浏览器访问某个网页时，像往常一样，下载三种文件，HTML+CSS+JavaScript。但是与以往不同，JavaScript不是文本文件，而是预先编译好的二进制文件。

2. 如果预先编译的做法可行，那么进一步的问题是，谁负责运行预先编译好的二进制码，JavaScript Engine还是native OS？考虑到JavaScript Engine将耗费可观的CPU时间以及Memory空间，让JavaScript Engine去运行预先编译好的二进制代码，是否有画蛇添足的嫌疑？

3. 在CPU时间和Memory空间的消耗成本方面，或许Simple语言比JavaScript更优越。但是作为另一种脚本语言，Simple的优势似乎不可能超越native语言。所以，用Simple语言去取代JavaScript，似乎不具有太大的吸引力。

总之，我们怀疑JavaScript以及JavaScript Engine都是历史演变中，在短暂时期内出现的过渡性的解决方案。运行效率更高，CPU和Memory成本更低的解决方案，开发难度会比较大，但是并非不可能。

恭喜：你意外获得【通宝】一枚

鲜花已经成功送出。

此次送花为【有效送花赞扬，涨乐善、声望】

大半夜睡不着，原来是有好文等着回复

语言这个东西呢，是人用来向机器描述的方式，所以谈语言，就有人的方面和机器的方面。两者都很重要，C语言的成功，除了UNIX这个大佬的支持，也是它自己作为人/机之间最短桥梁的优势 - 它是一个效率和可读性的有效折中。

所以说起js / simple，除了对机器这方面效率的考虑，也不能忽略人的因素。如果要取代js，那么目前存在的网站怎么办？目前已经学会js，热爱js的人怎么办？他们不跟Simple走，Simple只好等着新的程序员成长了。

在HTML引用Script Language的地方加上首缀，如果是“Simple：”，就把相应代码交给Simple Engine去解析运行。如果没有首缀，那么默认值是JavaScript。

这样，老的网页依然可以运行，但是新的网页，就可以使用新语言了。

转换成本太高了吧

ie客户端就可以切换vbscript和javascript，现在客户端还有用vbscript的吗？

让更多的人来使用。你看iphone带动了那么变态的objective C的发展。

还有微软的什么active control？

【3】 ChromeOS与Android，同室操戈，相煎何急

2009年7月10日BusinessWeek周刊上，有篇文章谈Google ChromeOS，重点是质疑ChromeOS的竞争矛头。表面上看，ChromeOS的竞争对手是微软的Windows。鉴于在PC领域全面挑战Windows的时机尚未成熟，所以ChromeOS选择了上网本（Netbook，MID），作为切入点，先占据一块根据地，然后谋求扩大根据地，从农村包围城市。

但是从实际效果看，一方面Google ChromeOS并没有对Windows构成实际威胁，另一方面，反倒是挖了自家兄弟，Android的墙角。文章给出的证据是，1. HTC和BORQ这样的厂商，在选择上网本的操作系统的时候，对于究竟是该用ChromeOS，还是用Android，感到很困惑。2. 预计到2011年，ChromeOS可能会占据上网本13%的市场份额，而Android的市场份额会降低到7%。

为什么Google会同时支持两套OSes，而且两套产品的市场定位有相当大的重叠？

Google的VP，Android的领军人物Andy Rubin的解释是，Android针对手机市场，专注于处理移动网络连接，手机电池管理等等。换句话说，Android与iPhoneOS竞争，而ChromeOS与Windows竞争。坦率讲，我们不认为Andy Rubin的解释非常有说服力。理由如下，

1. ChromeOS和Android的Kernel都是Linux。这两套Linux Kernels，似乎没有什么显著不同。

2. 关于Android在移动网络连接，电池管理方面有独到之处，说白了，这些独到之处其实就是一些libs。我们把这些libs通称为MiddleWare。ChromeOS与Android的MiddleWare或许的确存在差异，但是只要调整MiddleWare中包含的libs，这些差异很容易弥补。譬如，只要把Android的有关libs，移植到ChromeOS中去，ChromeOS也就具备了移动网络连接，电池管理的特异功能。

3. Android的主要卖点是Dalvik VM。有了Dalvik，应用开发商就能够用Java语言编写软件。ChromeOS似乎不包含Dalvik，但是把Dalvik移植到ChromeOS，似乎也不是一件非常困难的事情。

4. ChromeOS的特色在于基于浏览器来做GUI管理，而Android仍然延用传统的办法，靠调用APIs的办法来实现UI。把基于浏览器的GUI管理，与Dalvik相结合，难度不小，但是还是可行的。以后写专文探讨。

总之，我们认为，

1. ChromeOS和Android专注于不同的市场的传言，从技术上讲，这些的说法不太可信。

2. ChromeOS的矛头从长远来讲，或许是Windows，但是近期内，实际上冲击了Android的市场份额。从长期来讲，受威胁的很可能是Linux KDE和Gnome，而不是Windows。

3. ChromeOS和Android各有所长，最好的办法是融合，取长补短。从技术上讲，虽然有些难度，但是值得尝试。

两伙人都挺牛，谁也不福气谁，所以出了两套