18个月前我第一次听到微软准备以62%的溢价收购Yahoo的时候，我以为不是我疯了就是某些人疯了。似乎从AOL收购Time Warner后我就再也没听到过更蠢的收购议案了。我们不仅打算花44600000000的现金和股票来收购一个技术上已毫无优势，团队士气极为低落，企业文化又似乎已经跟不上时代的公司，而且会史无前例地将微软从创立以来第一次置于负债的境地，还不说收购以后对公司内部相关团队的士气影响以及我们将会浪费多少时间来整合对方庞大的工程资源等等不利的因素。
所幸的是，致远.杨同学很有骨气的拒绝了我们的offer，从而再次证明了一个古老的真理：你傻不要紧，只要你的对手更傻就可以。
而今晨的火线头条自然是微软和雅虎达成10年的搜索合作协议的消息，不过不同的是这一次，I feel so good about it.
1年半前收购雅虎，微软的项庄之意显然不是他们的搜索引擎技术。从后来发生的事来推算，Bing引擎那时已经在秘密开发中了。那么那个收购案的目的就很显然，那就是雅虎的搜索市场份额。基于搜索的在线广告这个东东是“赢家通吃”(winner takes all) 的游戏。试想，如果你是一个广告投放商，如果一个投放点能让你的广告被68%（Google的市场份额）的用户看到，而另一个投放点的观众只有8%（Bing的市场份额），你会选择哪一处呢？再进一步，如果你知道一家搜索引擎能针对68%的搜索流量来优化他们的广告显示结果和客户相关性，而另一家只能针对8%的数据来进行优化，你会选择谁呢？
所以说基于搜索的在线广告（注意，不是传统的静态广告。基于搜索的广告是根据用户搜索的关键字来显示广告的，而静态广告则一般就是投放在流量巨大的门户站点上，至于谁会看见谁会点击，只有天知道了）是一个“赢家通吃”或者“赢家制定规则”的游戏。排名靠后的参与者也还是可以参与市场定价，但相对于领头羊，他们必须承担大幅度折扣才能将自己的推销出去（简单说：Google可以要求广告投放的商家：点击一次你给我10分钱，而Bing就只能告诉同样的客户说：点击一次我只要3分钱。）
这也是为什么Google在搜索广告的市场占有率为68%，但却垄断了超过80%的营收。
所以对微软来说，将Yahoo的那20%多的用户群拿到手，确实是一种巨大的诱惑，因为这样一次性地将Bing这个选项（之前是Live Search）的吸引力提升到了另一个层次。即使从数字上看Google的市场份额并没有改变，但它实际上的营收却会收到巨大影响，因为现在它无法再以过去那样3.33倍（以上面假设的数字为例）于第二名的价格来要价客户了。
所以这次的合作协议，微软的目标并没有改变。只不过上一次，微软是急功近利地采取了一种低智的曲线救国的方法（通过并购），所幸的是杨同学发扬毫不利己专门利人的国际主义精神，毅然地让他作为创始人的ego超越了一切商业理智。
这次的协议中，微软无疑是大大的赢家。我们得到了最想要也是最重要的实质内容：流量（尤其是大量的长尾搜索流量，Google在企业级搜索上的优势还是明显的）还有用户元数据（用户的搜索历史，点击习惯，等等）。而后者对于Bing提升返回结果的相关性和进一步优化广告显示逻辑有着巨大的推动作用。Yahoo可以继续经营在线广告的投放渠道和客户关系，但这部分的内容的规模效应是很有限的。换句话说：如果微软想要参与现有的销售过程或者建立新的过程，并非难事。而Yahoo，已经和搜索引擎事业彻底告别了。
故垒西边，江山如画，这场微软和Google的旷世之战真是越来越精彩。
Google放出了Chrome OS的消息，于是大小媒体都像打了鸡血一样兴奋起来宣布Google正式向微软的核心阵地开始进攻了。
其实只有娱记和书虫才会这么想这么去挖掘新闻材料。思路稍微清晰一点的人都可以看透Google根本就没想搞一个真正完整的用户级操作系统。Linux搞了那么多年没搞成的东西，Google才没有兴趣也去搞一遍，就算它有这个实力有这个财力，它也知道是这件东东很可能是花了大钱还要吃不了兜着走的烫手山芋。
那为啥Google要左一个Android右一个Chrome OS地大张旗鼓呢？当然不是钱太多烧得慌，也不是时间太多闲得慌。Google多面多样的各种客户端应用背后唯一统一的最终思路就是将用户整合到它的服务平台（service back end）上来。Google希望看到一个分裂的原生平台世界（Mac, Linux, Windows, Symbian, iPhone, Android等等），越分裂越好。在一个分裂的客户端世界中，唯一统一的用户体验就是Google的服务平台。客户端的世界越分裂，就有越多的开发者不得不离开某一个原生平台而走向网络应用和网络服务。这才是Google真正想要的。它看似眼花缭乱的各种工作背后，唯一不变的主题和动力就是将越来越多的人（用户或开发者）吸引到它的服务平台（也是它的revenue generator）上来。
因此Google当然喜欢开源社区（当然，只要开源社区离他们的数据中心里的那些核心技术越远越好）。首先，开源社区最擅长的就是提供多样的解决方案，尤其在客户端方面。Google欢迎这样分化多样的选择方案。选择越多，对Google越有利。其次，开源社区还是一文不取的活雷锋，就好像Android平台，除了智能手机之外的内容几乎都是开源社区给创造的。而这次的Chrome OS也不例外。Google所要做的，就是抛出一个初步的想法或雏形，造成很大的声势，自然会有媒体给它免费宣传与关注，以后添砖加瓦的事大多就留给开源社区了。Google自己则将继续集中注意力于他们的核心竞争力上，也就是他们的服务后端。
如果说Google在向微软的核心阵地发起进攻，那也不是从Chrome OS开始的，那是从Google发布Gmail就开始了，从发布App Engine就开始了，从发布Docs就开始了。Chrome OS，只是很自然的下一个走下流水线的半成品。在新闻稿里，Google提到Chrome OS是计划在2010年的下半年发布的，那个时候，Win7都已经发布了一年了，市场上一定已经充斥着以Win7、以Ubuntu、以OS X为基础全面优化过的上网本（netbook），你还真的以为Google指望靠这个迟到了许久的产品在netbook市场上大赚一笔？
3月份从Windows Live转到Windows Embedded后，越来越多地需要与C/C++相依为命了。以前在C#里写点字符串处理的东西基本不用动什么脑子，现在单单是把两个字符串连起来，就要调用一个有4个参数的API。
最近在做的一个项目顶层的用户界面(UI, User Interface)还是选择用C#/WinForm写了，毕竟再用MFC之类的东西，身心受不了那个摧残。不过底层真正实现功能的API还是必须要用C/C++来写（有很多客观的原因必须如此），所以一个必然需要解决的问题就是如何让用托管代码写成的UI层来调用用非托管代码写成的API层里的函数/类。也不知这样的事大家现在是否还经常需要做，不知会用COM/ATL的还有多少人，不过既然就此做了一些调查，我想还是把结果整理一下，写下来，也许对一些朋友会有用呢。
本文只讨论如何从托管代码调用非托管代码，其实反向操作（非托管代码调用托管代码）也有很多类似的技术，大家可以自己查一下资料。
基本上从托管代码调用非托管代码的函数/类型有一下几类方法：
1. 通过Platform Invoke (P/Invoke)
这个在托管代码需要调用Windows API的时候是很常见的，比如要调用kernel32.dll里的SetDllDirectory这个native API，只要这样做就可以了：
using System.Runtime.Interopservices
public MyClass
{
[DllImport("kernel32.dll", SetLastError=true)]
static extern bool SetDllDirectory(string lpPathName);
...
public static void CallSetDllDirectory(string path)
{
...
SetDllDirectory(path);
...
}
}
利用P/Invoke最大的麻烦可能就在于这个native函数的P/Invoke的签名应该如何申明。最常见的一种方法叫做google，就是你把TheAPIYouWantToCall和P/Invoke这两个关键字放在一起google一把，基本就应该找到了，第一个连接十有八九是来自www.pinvoke.net这个网站。
不过如果你要是说你不喜欢Google怎么办？Google上找不到怎么办？要是Google当掉了怎么办？要是Google因为传播色情信息被封锁了怎么办？当然你可以说：我没有Google我有Bing，那也是可行的。不过其实还有更直接的方法，在2008年1月的MSDN杂志上的CLR Inside Out的专栏里就有这么一篇文章：Marshaling between Managed and Unmanaged Code，其中介绍了P/Invoke Interop Assistant这个工具。你不但可以通过这个工具来查找绝大多数公开的Windows API的P/Invoke的签名，而且也可以用它来产生你自己写的native API的P/Invoke签名，很方便。你可以在这里下载这个工具。
2. 通过C++/CLI wrapper class
这个方法主要是利用Managed C++来写一个封装函数/类，并以此来调用非托管的函数/类，而在另一边，用Managed C++写成的封装类的dll又可以直接被C#等托管代码来调用。
假设你有如下的C++类：
class __declspec(dllexport) NativeClass
{
public:
static void Func(LPTCSTR);
...
};
你可以在Visual Studio中建立一个Visual C++的CLR空项目：
记得调整配置的类型：
然后编写如下的Managed C++类：
public ref class MCppClass
{
public:
static void Func(String^ str)
{
NativeClass::Func((LPTSTR)Marshal::StringToHGlobalUni(str).ToPointer());
}
...
};
编译后生成的dll就可以直接被托管代码调用了。当然，关于托管代码变量和非托管代码变量之间marshaling的问题也是很头疼的，不过这个不是本文的讨论内容。
3. 通过CALLI instruction以及Reflection.Emit直接调用非托管代码
CALLI是Intermediate Language (IL)的一个指令。老实说我也不太清楚这个东东怎么用，只是看有的文章提到说可以如此做，但没有深入地研究一下，有兴趣的同学可以参考一下David Broman的这篇文章。
4. 通过COM interop
这个就留待明天的Part II再讲吧，因为我还想顺带提一下COM里的一些相关内容，篇幅可能有些长，并且时间也不早了…
