The Microsoft® Shared Source CLI is a working implementation of the ECMA-334 and ECMA-335 standards (known to us mortals as the Common Language Infrastructure and the C# programming language). The source code in this distribution builds on FreeBSD, Mac OS X, and Microsoft® Windows. (There are instructions on how to do this, as well as hardware requirements, below.) Besides the CLI and the C# compiler, this distribution contains a JScript compiler written entirely in C#, as well as a wide variety of tools, utilities, managed classes, and samples. It is intended to be an appealing new platform alternative for people who want to learn, to teach, to tinker, or to experiment more formally with computer languages and computer language infrastructure.
This copy of the Shared Source CLI is being distributed as source code under a Shared Source license. It is important for you to read through the brief license that is included with your copy of this distribution now, because once you examine the code or use it in any way, you will be bound by the terms of this license. For more information about the Shared Source program at Microsoft, take a look at the Microsoft Shared Source Initiative Web page at www.microsoft.com/licensing/sharedsource or search www.microsoft.com for "Shared Source".
This is the third release of the Shared Source CLI, and it is for
non-commercial, experimental use only. Microsoft will be updating this distribution
periodically. The distribution is completely unsupported, although the
development team will be checking in on the
microsoft.public.shared_source.cli newsgroup.
By default, the build scripts in this distribution produce an optimized debug build of the tools and runtime. This is because we believe that most of you are programmers, and that you will want to be spelunking around in the debugger but you still want reasonable execution performance. If you want maximum source debugging support you should choose a checked build which will turn off optimizations and allow better source-level debugging. If you want to get more performance, you can build a free build, which will execute code considerably faster. For instructions, see the detailed build instructions in building_sscli.html.
Colloquially, we refer to this project as Rotor. Why? Well, you'll find the following definitions for the word:
It's obvious! Rotor is all of these and more...
Please read the license before you begin.
OK, having taken care of that, Rotor has been built and tested on Windows, FreeBSD, and Mac OS X. If you want to build and run the source code, you'll need some additional software depending upon your OS. The Rotor build process uses Perl in several ways, both to run the test harness and as a way to autogenerate some utility code. On Windows you will need Microsoft Visual Studio® .NET as well as Perl. (The Rotor development team currently uses ActivePerl 5.6.1.630, from ActiveState, but perl.org is always a good bet as well.) On FreeBSD, the only thing that you will need in addition to a FreeBSD developer distribution is Perl. (We are currently using 5.005_03). There are several samples that uses the Tk 8.4.0 widget set; if you choose to build this, Tk is available from www.scriptics.com.
As far as hardware goes, we really recommend having 512M of memory in your computer. While we've heard of success in building on machines with less, it can be mighty slow (and the swap thrashing can be horrific) Truth be told, using the Windows compilers, 256M seems to work pretty well, but gcc seems to use more resources and you'll see more performance degradation on FreeBSD and Mac OS X because of this. As far as disk space goes, 100 megabytes should be sufficient if all you will be doing is viewing the source, but if you are doing active development (especially running the test suites) you will need at least a gigabyte of free disk space.
Please note that the Rotor distribution was only tested on operating systems using English locales. There are known problems with attempting to build and execute Rotor on other locales. If you avoid using locale-specific characters in the path to the source code, you may be able to use Rotor on operating systems using other locales.
Windows
FreeBSD
Mac OS X
For more information you might want to peruse the documentation index for more links into the documentation set. We recommend that you also have either Visual Studio .NET or the .NET Frameworks SDK as secondary documentation to the ECMA specifications.
We've included a detailed document about building Rotor, but if you are impatient, here are very brief instructions to get you up and running quickly.
On FreeBSD: Once you have extracted the contents of the
tarball (tar xvfz will work), you should source the
contents of either env.sh or of env.csh in the root of
the distribution, depending upon which shell you are using. For example, in csh
you might type the following command: source env.csh Once this
script has run, type ./buildall in the same instance of the shell,
which will initiate the build process.
On Mac OS X: Once you have extracted the contents of the
tarball (StuffIt 7.0 or gnutar), in a console window you should source the
contents of either env.sh or of env.csh in the root of
the distribution, depending upon which shell you are using. For example, in csh
you might type the following command: source env.csh Once this
script has run, type ./buildall in the same instance of the shell,
which will initiate the build process.
On Windows: Once you have extracted the contents of the
tarball using your favorite archiving utility, open a command window and run the
env.bat script from the sscli (root) directory of the distribution.
You need to run the script from this directory because it uses the current
directory to set up subsequent environment variables. After this, in the
same window, type buildall, which will initiate the build process.
In order to be useful on both systems based on UNIX systems and Windows, text files in the archive are
linefeed terminated. If you are running Windows, you'll want to view these
files in an editor that handles this case automatically (many do, including
WordPad and the Visual Studio editor), or else use a utility program to remove
the convert the linefeeds to Windows-style carriage-return/linefeed termination.
Once the build has successfully finished, you should be able to compile and execute the simple "hello world" test program by changing to the samples\hello directory (samples/hello on UNIX systems based platforms), and then typing:
csc hello.cs clix hello.exe
This will churn for a while (loading takes less time on the free build), and then print out "Hello World!" The program clix is a program loader for managed executables. The first line uses the C# compiler to produce hello.exe from hello.cs, a tiny program that prints "Hello World!" to the system console.
Assuming that hello.exe works, you are now able to compile C# sources using csc (the C# compiler), and JScript sources using the jsc compiler. Remember to always run Rotor programs in a shell that has been set up using the env scripts as described above. Also remember that managed executables need to be launched using clix in order to run under Rotor. For example, the JScript compiler must be run in this way.
You are almost certain to find that the map of the source code to very useful in navigating around the distribution. The document on building rotor will also be very helpful if you are modifying code; its scenario-based descriptions can be time-saving.
Rotor comes with a number of test suites covering various aspects of its implementation:
For more information refer to the testing_overview.html document in the sscli/docs directory.
The Shared Source CLI runtime is not intended for use as a secure environment, although its source code does provide a very good example of how a secure execution environment might be built. By default, strongname verification is turned off for several important public keys - see the release notes for details as to how strongnames work in this distribution.
The implementation of Rotor's global assembly cache and strongname verification system is completely separate from the implementation used by the commercial Microsoft .NET Framework, and because of this, there should be no interaction between the two. Turning off verification in Rotor will not impact the Microsoft .NET Framework on Windows in any way.
There are a small number of files in this distribution that carry their own licenses which are compatible with the Microsoft Shared Source CLI, C#, and JScript License. Anyone building modified versions of this code should be aware of and comply with these license terms.
Copyright (c) 2002 Microsoft Corporation. All rights reserved.