Microsoft 釋出Rotor，一場Shared Source對Open Source的速度比賽 (轉)[@more@]

釋出Rotor，一場Shared 對的速度比賽

:namespace prefix = o ns = "urn:schemas-microsoft-com::office" />

小氣的神

2002．03．28

Article Type: News

難度等級：1/9

版本：1.48

我想這是世界中一件有意義的事，某種程度上它會在今後幾年對Microsoft以及他的敵對者造成影響，當然現在我們不知道將是怎樣的影響和振動。不過我認為目前的 Microsoft 顯示出更多的“Steve Ballmer”特性，也許我們需要重新打量我們以前頭腦中的Microsoft，應該說，他在變化。

昨天，3月27日，Redmond 宣佈共享程式碼的CLI( Common Language Infrastructure) 和實現釋出。比起 Navigator 5.0的17 million 行來說它只有100多萬行,但這一百萬行程式碼（近1400個）足以滿足C#愛好者內心深處的好奇心，並且他們會為此激動不已。

Redmond解釋說該舉主要是推廣語言方面的創新和XML Services研究，並且主要針對大學和學術界，分析家也認為這樣的舉動將不會造成太大商業影響，同時Microsoft的批評者認為這主要是為了阻止的增長和打擊這種的開發原始碼的發展。一些觀察家認為目前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 多語言支援策略的核心和關鍵技術。C#作為C及C++家族中一個改進型的面向的程式語言而CLI則是.NET Framework的一個優良子集，主要提供一個執行時環境和開發和分發XML Web Services的基本類庫。Redmond這次發表的Shared Source CLI Beta包括了這兩部分甚至更多。

不過值得注意的是，Microsoft非常強調其Shared Source性質而不是Open Source，這符合這家公司一貫對於GPL( 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等等，甚至 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 and Free

l Compilers that work with the Shared Source CLI for C# (ECMA-334) and

l Development tools for working with the Shared Source CLI such as assembler/disemblers (ilasm, ildasm), a deger (corg), metadata introspection (metainfo), and other utilities

l The PlatfoAdaptation Layer (PAL) used to port the Shared Source CLI from Windows to

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 w 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 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 develo their own CLI implementations will find the Shared Source CLI an indispensable guide and adjunct to the ECMA standards.

如何獲得它？

.microsoft.com/download/.netframesdk/CLI/Beta1/WXP/EN-US/sscli20020326.tgz">

FAQ？

?URL=/downloads/sample.asp?url=/msdn-files/027/001/901/msdncompositedoc.xml">

需要的環境

On Windows XP you will need:

l .NET

l 5.6 (available from )

l Archiving utility of choice – or other

You will need FreeBSD 4.5 if you work with the Shared Source CLI on FreeBSD.

提示：

l 官方申明目前還不支援但已經有人嘗試並執行成功：

I just built it on 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

lent!

（以上資訊來自新聞組，有人認為XP的限定是為了促銷而他們希望未來有更多人會工作XP下,最重要的可能是整個Rotor team是在XP環境下工作的，所以不保證未來是否會有變化）

l 如果你不熟悉FreeBSD 那麼小心你的雙啟動和先(可以考慮試一試 Workstation軟體)。

l 找到

l 最新的有關，

l Shared Source CLI的程式碼名叫“Rotor”，你到新聞組和一些內部網站上可能會碰見它。

l 無論你多麼激動或慌亂都一定在Unzip後的第一時刻閱讀ReadFirst.html

l 編譯時保證你有足夠的空間，越大越好。

l 文件連結中的architecture_guide.html似乎丟失，你可以從看到同樣性質的文章

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 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 pessions 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, and . 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 s 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 lwithin 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 APIs used in Rotor

· Crypto code used to support stroames 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, Appains, 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.)

· -- 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 i/sscli/clr/src/bcl/system">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 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 (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.

Microsoft 釋出Rotor，一場Shared Source對Open Source的速度比賽 (轉)