Microsoft 发布Rotor，一场Shared Source对Open Source的速度比赛
小气的神
2002．03．28
Article Type: News
难度等级：1/9
版本：1.48
我想这是dotNET世界中一件有意义的事，某种程度上它会在今后几年对Microsoft以及他的敌对者造成影响，当然现在我们不知道将是怎样的影响和振动。不过我认为目前的 Microsoft 显示出更多的“Steve Ballmer”特性，也许我们需要重新打量我们以前头脑中的Microsoft，应该说，他在变化。
昨天，3月27日，Redmond 宣布共享代码的CLI( Common Language Infrastructure) 和 C# 实现发布。比起Netscape Navigator 5.0的17 million 行源代码来说它只有100多万行,但这一百万行代码（近1400个文件）足以满足C#爱好者内心深处的好奇心，并且他们会为此激动不已。
Redmond解释说该举主要是推广编程语言方面的创新和XML Web Services研究，并且主要针对大学和学术界，分析家也认为这样的举动将不会造成太大商业影响，同时Microsoft的批评者认为这主要是为了阻止Java的增长和打击Linux这种的开发源代码的发展。一些观察家认为目前Linux的发展放缓，特别是桌面应用方面，无疑Redmond现在的举动会触及到他们某些敏感的想法。
8个月前Microsoft被指责对dotNET开放结构及跨平台使用能力的夸大宣传和无心承诺，2001年7月，著名的Linux桌面环境GNOME开发商Ximian公司出于改进开发工具的需要，开始启动一个名叫Mono的开放源码项目，旨在开发Linux版的.NET。不过目前看来Microsoft和他的伙伴率先进了一球。而且从2000年10月Microsoft向ECMA提交有关C#和CLI的规范，一直到2001年12月被ECMA批准看来，Microsoft也都不断的向Sun施加压力，相比起来在2000年，Sun公司撤回了他自己的Java ECMA申请过程。
C#（ECMA－334）和CLI（ECMA－335）都是 Microsoft .NET Framework多语言支持策略的核心和关键技术。C#作为C及C++家族中一个改进型的面向组件的编程语言而CLI则是.NET Framework的一个优良子集，主要提供一个运行时环境和开发和分发XML Web Services的基本类库。Redmond这次发表的Shared Source CLI Beta包括了这两部分甚至更多。
不过值得注意的是，Microsoft非常强调其Shared Source性质而不是Open Source，这符合这家公司一贯对于GPL(GNU General Public License )的理解，老实说他们不相信GPL能够保证自己对自己代码和权力的控制，也不愿意跟GPL产生任何关系，特别是自己核心的产品。不过Microsoft自己有产品是遵循或支持GPL的， Andy Patrizio曾吃惊的发现Microsoft至少有一个这样的产品：Interix。Microsoft对于这个产品有些工具是在 GNU GPL下 Released非常的讨厌，但处于对以前license的尊重，Microsoft不得不继续在GPL下Release以后版本的代码。Microsoft不是一家小公司，所以他不会轻易的接近GPL,以免只要有一样接触到GPL，那么所有的产品都可能会变成GPL的 （Don Box说GPL是一种“Viral licences”）如果说为研究学习和进步的需要公开源代码，Microsoft一般会选择Shared Source。Window CE.NET和这一次Shared Source CLI等等，甚至Windows 2000/XP/.NET Server都是这样。尽管Microsoft被他的对手认为是极其无赖的，但本质上他符合美国商业最基本的一条规则：你可以选择不玩这个游戏，但只要你进入，那么你必须遵守这个游戏中的所有规则。
好了，先不管为什么不是“Open Source”的原因和可能的争论， 看看这个11M的软件包中有些什么，能干什么吧。(不喜欢翻译所以不翻译了,见谅)
有什么特色？
The Shared Source CLI archive contains the following technologies in source code form:
l An implementation of the runtime for the Common Language Infrastructure (ECMA-335) that builds and runs on Windows XP and FreeBSD
l Compilers that work with the Shared Source CLI for C# (ECMA-334) and JScript
l Development tools for working with the Shared Source CLI such as assembler/disassemblers (ilasm, ildasm), a debugger (cordbg), metadata introspection (metainfo), and other utilities
l The Platform Adaptation Layer (PAL) used to port the Shared Source CLI from Windows XP to FreeBSD
l Build environment tools (nmake, build, and others)
l Documentation for the implementation
l Test suites used to verify the implementation
我能用它做什么？
There is a wealth of programming language technology in the Shared Source CLI. It is likely to be of interest to a wide audience, including:
l Developers interested in the internal workings of the .NET Framework can explore this implementation of the CLI to see how garbage collection works, JIT compilation and verification is handled, security protocols implemented, and the organization of frameworks and virtual object systems.
l Teachers and researchers doing work with advanced compiler technology. Research projects into language extensions, JIT optimizations, and modern garbage collection all have a basis in the Shared Source CLI. Modern compiler courses can be based on the C# or JScript languages implemented on the CLI.
l People developing their own CLI implementations will find the Shared Source CLI an indispensable guide and adjunct to the ECMA standards.
如何获得它？
http://download.microsoft.com/download/.netframesdk/CLI/Beta1/WXP/EN-US/sscli20020326.tgz
FAQ？
需要的安装环境
On Windows XP you will need:
l Visual Studio .NET
l Perl 5.6 (available from http://www.perl.org)
l Archiving utility of choice – WinZip or other
You will need FreeBSD 4.5 if you work with the Shared Source CLI on FreeBSD.
提示：
l 官方申明目前还不支持 Windows 2000 但已经有人尝试并运行成功：
I just built it on Win2000 and ran the test suite (cd tests; rrun.pl).
Here are the results:
RRUN: Summary:
RRUN: Run time - 0h 36m 49s
RRUN: Processed - 1574
RRUN: Passed - 1574
RRUN: Failed - 0
Excellent!
（以上信息来自新闻组，有人认为XP的限定是为了促销而他们希望未来有更多人会工作XP下,最重要的可能是整个Rotor team是在XP环境下工作的，所以不保证未来是否会有变化）
l 如果你不熟悉FreeBSD 那么小心你的双启动系统和备份先(可以考虑试一试VMware Workstation软件)。
l 找到合适版本的Perl
l 最新的有关SSCLI的书，
l Shared Source CLI的代码名叫“Rotor”，你到新闻组和一些内部网站上可能会碰见它。
l 无论你多么激动或慌乱都一定在Unzip后的第一时刻阅读ReadFirst.html
l 编译时保证你有足够的空间，越大越好。
l 文档链接中的architecture_guide.html似乎丢失，你可以从O'Reilly's看到同样性质的文章
The lay of the land
Points of interest in this directory:
· license.txt, licensed_file_list.txt, and license_banner_for_sources.txt
· env.bat, env.sh, and env.csh
· buildall and buildall.cmd
To build the Shared Source CLI, you must be running within a sh- or csh-flavored shell on FreeBSD, or a command window in Windows. The build procedure is detailed in this document, but to summarize, you first set up your environment by running one of the flavors of the env script, followed by running buildall. Note that through some filename and file permissions trickery, typing "buildall" on Windows will cause buildall.cmd to run, while typing it into a FreeBSD shell will cause the shell script named buildall to be run. The env scripts aren't quite as automagic -- on FreeBSD, depending on the shell that you favor, you will have to "source" either env.sh or env.csh; on Windows, you may just type env into a command window.
But wait! Before you go and build the CLI, first you should take a look at the license! The file named license.txt contains the Microsoft Shared Source CLI/JScript/C# License, which applies to this entire distribution. The file named licensed_file_list.txt contains the "bill of materials" for the distribution, and the file named license_banner_for_sources.txt is the copyright banner that is injected into most of the files found in this distribution. There are a few files in this distribution that are licensed under other licenses, and we have preserved the copyright and license notices for these.
sscli/docs is documentation for the Shared Source CLI
This document resides in this directory, as well as a very useful index of all of the doc that is part of the distribution.
Happy browsing!
sscli/pal contains implementations of the Platform Adaptation Layer (PAL)
Within the pal subdirectory, we find two subdirectories, unix and win32. The "unix" directory contains the implementation of the FreeBSD pal (don't ask why it isn't named FreeBSD...) and, logically enough, the "win32" directory contains the Windows PAL. There is also an important header file, named rotor_pal.h, which declares all of the APIs that a developer building a new PAL would have to implement. See the PAL Specification for more details on this topic.
The Win32 PAL is primarily an exercise in calling through to the underlying Win32 API after logging the call and sanity-checking parameter values in some cases, but the code for doing portable exception handling might be of interest.
The FreeBSD PAL, on the other hand, is a substantial piece of work. Mapping Win32 semantics onto BSD semantics is non-trivial, and a number of interesting (and possibly controversial :) design decisions lie within this directory. From Unicode support to exception handling to memory-mapped files to debugger support to sockets and file I/O, there is a lot to look at here.
sscli/palrt/src contains the implementation of the "PAL runtime"
In order to make life simpler for developers who wish to build new PAL implementations, some of the more generic or reusable implementation details have been broken into a separate library, called the PAL runtime. If you're not implementing a PAL, this directory still might be interesting -- it contains a number of odds and ends, including:
· Implementation of the COM APIs used in Rotor
· Crypto code used to support strongnames and the runtime
· C runtime functions
· Math and decimal math routines
· Support for streaming over memory
· String, url, and pathname parsing and manipulation
· Configuration and resource loading
· Code used when calling from platform-native code to managed code
The PAL runtime is used by the FreeBSD PAL. Note the set of "cut down" windows header files in sscli/palrt/inc directory; these are included in order to pull in these API helpers. If you wish to implement a new PAL, you will probably want to use the same technique.
sscli/tools is source code for portable build tools
Once a PAL has been created, using the native tool chain for whatever platform is being built, a set of portable build tools are then built against the PAL. This is the bootstrap that enables the bulk of the build process; these tools use the PAL APIs to accomplish their work. Documentation for all of these tools can be found in the sscli/docs/buildtools directory; see in particular build.exe, binplace.exe, and nmake.exe.
sscli/clr/src contains a lot, including the runtime and the C# compiler
Points of interest include these sub-directories:
· vm -- This directory has the bulk of the execution engine, including the garbage collector, the class loader, the type system, error reporting, AppDomains, Assemblies, delegate support, reflection, security, and the code manager. There are numerous interesting files to examine here. (For those curious about the build process, note that vm has a "dirs" file, but the "sources" file can be found in the vm/wks subdirectory.)
· csharp -- This directory contains the sources for the C# compiler (csc.exe) and the assembly linker (al.exe).
· utilcode -- This directory contains core routines used throughout the runtime, the tools, and the C# compiler. It includes code for path handling and parsing, array and hashtable management, C runtime routines, character case support, library and assembly loading, debugging and logging instrumentation, synchronization, as well as utility code for many miscellaneous tasks such as formatting, guid creation, error handling, and registry and config access.
· md -- This directory contains a metadata reader and writer.
· fjit -- The Rotor JIT compiler and its verifier can be found here.
· fusion -- Code that implements binding to assemblies, policy checking for the binding process, and the Global Assembly Cache can be found in the fusion directory.
· bcl -- C# code for the ECMA Base Class Libraries can be found in this directory. Most of the interesting code is in system and its sub-directories.
· debug -- This directory contains the source code for the managed code debugger (cordbg.exe).
· ilasm -- An assembler for the Common Intermediate Langauge.
· ildasm -- A very useful disassembler.
· tools -- This directory contains sources for the PEVerify utility, a managed code launch utility (clix.exe), a metadata dump utility (metainfo.exe), a reader/writer for managed debugger symbols, and numerous other utilities and tools.
· dlls -- This directory contains sub-directories for all of the native shared libraries that are linked as a part of the build process. Anyone wishing to build tools against these shared libraries may find the information in these directories useful.
sscli/fx/src contains sub-directories of C# code that implement frameworks
Several sub-directories contain implementations of major namespaces, such as regular expression support, XML support, and networking. There is also some code for miscellaneous features in these directories.
sscli/managedlibraries/remoting contains C# code for remoting
These frameworks are not part of the BCL, but will be useful.
sscli/jscript/engine contains the sources for a JScript compiler
This JScript compiler is completely written in C#, so it is interesting both as an example of a large C# project and as an example of how to compile against the CLI intermediate language. The compiler uses the System.Reflection classes extensively in producing its managed executable output. JScript is also a very "dynamic" language, and as such, demonstrates many interesting compiler techniques for generating IL and runtime structures on the fly.
sscli/build only exists after you have built the code
It contains a number of important things at this point, including the executables and shared libraries themselves, as well as your debugging symbols and the directory used as the Global Assembly Cache. (Note that some executables can be found in both the root directory, while others are in sdk/bin.)
Each target that you build (checked, fast-checked, or free) will have its own set of build subdirectories.
sscli/tests contains numerous smoke tests
The tests directory contains a large number of small tests that can be used, once you have built the sources, to avoid regressions while modifying the code. The file rrun.pl is a perl driver (with useful comments embedded within it) that can be used to run the tests for the runtime itself, while the palsuite sub-directory contains tests for the FreeBSD PAL implementation.
(上面英文文章来自Rotor的 map.html, Microsoft版权所有 )
