摘要:  Object-orientation addresses the architecture within a single building (a “service”), while service-orientation addresses the issues around city planning (a “system”).                                    --- Indigo FAQ...[阅读全文]

摘要:“All schemas are relative! They are not the absolute truth. The absolute truth is whats on the wire.”                                                                                                             ----- Don Box on SOA     Don Box在关于SOA (Service-Oriented Architecture)的MSDV TV Show中谈到Xml Schema在SOA架构中的地位，并且引用了Steve Maine的话: “XSD is not a type system”。Steven给出的原因是XmlSchema不符合Type System的三个特点：Closed,  Definitive和Authoriatative。 Closed: Steve Maine认为“XSD supports open content via extensibility elements such as ”。但是在我看来大多数编程语言都有与在功能上类似的构造。C#的object、C/C++的void*都可以用来支持完全开放的类型扩展，我们无法据此否定XSD的Type System本质。 Definitive: 虽然大多数编程语言不支持XSD的所谓Optional Element，但是通过上面的object/void*扩展，这些语言完全具备和XSD等同的表达能力， 仅仅是实现方法的差异也不足以把XSD排除在Type System之外。 Authoriatative: Steve认为与传统的Type System不同，同一个XML文档可能会存在很多不同的XmlSchema定义。Don Box关于这一点的注释（Search “XSD as a Type System”）很是切中要害：“The point that Steve misses however is that once you've decided which XML Schemas to use, nominal typing kicks in. At that point, there is an authoritative definition for each EII and AII......[阅读全文]

摘要:  “Microsoft is sharing source code with customers, partners, governments, and competitors. ”    2003年底，Microsoft通过MVP Source Licensing Program (MVPSLP)向MVP开放了Windows 2000、Windows XP和Windows Server 2003操作系统及其主要Service Pack的源代码。MVPSLP允许MVP阅读、参考这些操作系统的完整源代码，但是不能对原码进行修改或者将源代码用作技术支持以外的其他用途。   我在2003年10月提交了MVPSLP的申请，今年2月收到并且签署了相关的Agreement，3月初收到用于访问Code Center Premium的SmartCard/Reader和Certificate，并且简单的浏览了一下Internet Explorer的源码（其实没看出什么名堂）。Microsoft提供了一个Online的Source Code Server，以避免在客户端直接保存完整的操作系统源代码带来的维护负担和安全隐患。一方面我们可以在浏览器里通过SSL连接（需要客户证书认证）直接浏览源代码；另一方面，Source Server保存了各个操作系统版本的Symbol File (*.PDB)，通过使用WinDbg我们可以直接进行源代码级的Kernal调试。这里有一段演示，是通过WinDbg单步跟踪CoInitialize的（Cool, Isn't it? ）。     目前Souce Server还不能及时更新各个Hotfix的Symbol File，而我不幸总是很及时的Apply 各种Hotfix，这就导致了在我的机器上不能原码级调试一些经常更新的系统文件（NTDLL.DLL等等）。正准备另起炉灶安装一个“赤裸裸”的Windows 2000，专门用来调试。     3月15号的New York Times上有一篇关于Microsoft Shared Source Program的文章，原来包括政府机关、Microsoft的合作伙伴、当然还有MVP在内，MSSP已经发布了100万个源代码许可（第一百万个说不定是我，不知道有没有什么奖品)！看来Windows的源码虽然还算不上“地球人都知道”，可比Coca-Cola的配方要公开多了。    P.S. Rotor(Shared Source CLI)实际上是Microsoft Shard Source Program的一个部分，它是.NET Framework源代码经过裁减以后的一个分支。包括了所有ECMA标准的内容，但是没有Asp.net和Windows Form部分。...[阅读全文]

摘要:   关于开心的问题，Saucer都来了，我也来凑热闹。  这个问题在CSDN上碰到好几次，我每次都只给出了简单的答案：不要参考Task Manager的Mem Usage数据，那个数据的大小对程序性能没有直接影响。 下面是我分析这问题的一些思路，希望对对这个问题感兴趣的朋友有所帮助。（还有一个原因——很久没有update blog，被开心“警告”了... ）  Q: Is .NET Alone? A: Nope!  前面Saucer说过了，这不是.NET的问题，所有Windows程序都有类似的行为。例如下面的C程序：    void main { while(1); }   //死循环，便于我们察看Task Manager  初次运行在我的机器上Mem Usage是632K，把Console最小化以后再恢复，Mem Usage变成了36K。显然，这不是一个.NET独有的问题，而是Windows Memory Management的问题。那么和.NET的GC机制也不会有太大的关系——虽然问题的表现形式很容易让人联想到GC。  Q: How much memory does my program use? A: 回答这个问题并不容易。先来看看操作系统虚拟内存管理的一些基本概念：每个Windows进程都拥有4G的地址空间，但是你的机器显然没有4G的物理内存。在多任务环境下，所有进程使用的内存总和可以超过计算机的物理内存。在特定的情况下，进程的一部分可能会从物理内存中删除而被暂存在硬盘的文件里(pagefile)，当进程试图访问这些被交换到pagefile里的内存的时候，系统会产生一个缺页中断(page fault)，这时候Windows内存管理器会负责把对应的内存页重新从硬盘调入物理内存。  在某个时间内，一个进程可以直接访问到的物理内存（不发生缺页中断）叫做这个进程的Working Set；而一个进程从4G的地址空间当中实际分配(commit)了的、可访问的内存称为Committed Virtual Memory。Committed VM可能存在于Page File当中，WorkingSet则一定位于物理内存。  所以要回答上面的问题先要反问一句：What're you talking about? Physical Memory or Committed Memory?  Q: What is this "Mem Usage" data? A: From Task Manager Help: In Task Manager, the current Working Set of a process, in kilobytes.   Mem Usage这个名字多少有些误导。它只表示这个进程当前占用的物理内存，也就是WorkingSet。WorkingSet不表示进程当前“占用”的所有虚拟内存，该进程可能还有一部分数据被交换到pagefile当中。这些数据只有在被访问的时候才会被加载到物理内存。  Task Manager有另一列数据：VM Size，表示了一个进程分配的虚存(Committed Visual Memory)——实际的定义要比这个复杂一些，但这个定义对我们目前分析的问题已经足够了。以前面的C程序为例，在最小化前后的VM Size都是176K，并没有变化。  所以，结论很简单：当一个Windows程序被最小化的时候，Windows内存管理器把该进程的WorkingSet减到最小（根据先进先出FIFO或者最近最少使用LRU），把大部分数据交换到pagefile里。这很容易理解：我们通常总是希望为前台的应用程序留出更多物理内存，从而具有更好的性能。当该程序从最小化恢复的时候，Windows也不会完全加载程序的所有虚存，只是加载了必要的部分。这也很容易理解：程序启动阶段的代码通常在启动之后很少访问（对.NET程序尤其如此，向fusion这样的模块在程序正常加载之后如果没有用到Reflection通常用不到）。  Q: So, Do we want a smaller workingset, or a larger one? A: It depends. Conventional Wisdom tells us: The smaller, the......[阅读全文]