Slashdot Mirror
MS Releases .NET Source, Sort Of
cam_macleod writes "A friend at Microsoft (he's a nice guy, really!) pointed me to their release of the Common Language Infrastructure (CLI) source, which builds successfully on Windows, FreeBSD, and MacOS X 10.2 -- he says Linux too, but their website strangely doesn't mention it!"
Remember "many eyes".
.NET it all your fault.
If there are any security problems with
(I'm blind, don't blame me!)
This is not new. Microsoft released this long ago in an effort to show that .NET really *is* cross platform. Here are the changes (as listed on the website):
Support for Mac OS X 10.2.
Additional code clean-up and bug fixes.
Debugger improvements.
Class reference documentation (separate archive) and additional samples.
Build system improvements and additional test cases and tool improvements.
I'm not that familiar with the .NET infrastructure, but does this mean that I can take a .NET application that works on my Windows box and uses the Win32 GUI and have it work on my Linux Box?
Just wondering if this thing actually "works" or if its just part of the whole picture.
Read the license here
This is nowhere near Open Source / Free software. The license specifically states that you cannot use the code for any commercial purpose whatsoever--even writing your own software to use for your own purposes in running a business. Furthermore, the license states:
You may use any information in intangible form that you remember after accessing the Software. However, this right does not grant you a license to any of Microsoft's copyrights or patents for anything you might create using such information.
In other words, they're trying to use software patents to keep people from writing their own implementations of C# / CLI libraries and software.
Which all boils down to: Microsoft wants a programming language for which you have to pay them royalties just to use, with the exception of academic use. They realize that their monopoly on operating environments is crumbling so they want to "own" and control the "next C++ or Java". My opinion: boycott this crap.
the only "funny" part of the license is "you may not distribute modifications of the Software under terms that purport to require the Software or derivative works to be sublicensed to others", a very straight, and extremely amusing ("purport"??) attack on the GPL. M$ maynot be a lot of good things, but they certainly ARE FOCUSSED! ;)
also, can someone please explain to me the impliations of
Can someone please enlighten me?
LinuxGhoul
Sigura Non Grata
It is interesting to note that many of the files have a comment with a date of June, 1999.
it's not so much an attack on the GPL, it's just saying tht you can't relicense derivatives under something like the GPL. In much the same way as you can't relicense derivatives of GPL work under any other license.
It only works under 10.2. strtok_r was added in Jaguar.
Something about that experience felt really... dirty.
And for the unofficial 'benchmarks' on my G4/800 (because printing out "Hello World!" is a valid benchmark
What is the Microsoft Shared Source CLI?" 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:
An altocumulus cloud found in the lee of large mountain barriers, that circulates around its horizontal axis. An important part of a cryptographic encoding or decoding device. A quantity having magnitude, direction, and position. The rotating part of a dynamo, turbine, distributor, compressor, centrifuge, blower, or motor. A device that propels a ship forward in a cross-wind, exploiting the Magnus effect. The rotating airfoil assembly on rotary-wing aircraft. It's obvious! Rotor is all of these and more...
Getting Started 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.
Summary of System Requirements
Windows We've tested the distribution on Windows XP and Windows 2000. We recommend Windows XP. Microsoft Visual Studio .NET installed. You must, at a minimum, install the Microsoft Visual C++ .NET product.
Perl installed and in the path.
Tk installed if you want to run all the samples.
256 MB of memory (suggested minimum).
100 MB of free disk space to expand the archive.
One gigabyte of free disk space to build the distribution.
FreeBSD We have tested the distribution on FreeBSD 4.5, 4.6, and 4.7. We recommend FreeBSD 4.7. Developer distribution (which will include the gcc compiler and other build tools) Tk package installed if you want to run all the samples. 512 MB of memory. If you do choose to use less memory then make sure your swap space is at least four times your memory size. 100 MB of free disk space to expand the archive. One gigabyte of free disk space to build the distribution.
Mac OS X Mac OS X 10.2. Apple Developer Tools. Tk package installed if you want to run all the samples. 256 MB of memory: 512 MB recommended. Ensure the BSD subsystem is installed. (This is the default installation.) Stuffit(TM) Expander 7.0 will unpack the archive. Otherwise use gnutar and not the default tar. One gigabyte of free disk space to build the distribution.
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.
Building and Running Code 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.
FYI, the FreeBSD port was done by some folks at Corel.
----- rL
I hope mono is able to port it eventually.
--Me