Rotor: Shared Source CLI

Oink.NET writes "The O'Reilly Network reports on an unannounced BOF session at BSDCon 2002 regarding Rotor, a shared souce implementation of Microsoft's Common Language Infrastructure that currently runs on Windows and FreeBSD. It relies on a Platform Adaptation Layer, similar to Apache's Portable Runtime, that simplifies porting to other OS's. As to the licensing terms, the Rotor FAQ says "Microsoft intends to provide very liberal non-commercial licensing terms and is interested in gathering community input on the design of the license." Wonder if that includes Slashdot community input..."

Why FreeBSD, here's my opinion

[Baca]

"Why FreeBSD?

One goal of creating a shared source implementation of the ECMA CLI is to prove that the technical choices being made by the ECMA technical group can be implemented on multiple operating system platforms. FreeBSD seemed like a good choice, since it is both a representative UNIX implementation and a platform that has historically encouraged unencumbered experimentation. Microsoft has no plans for supporting other platforms or chip architectures in this implementation at this time."

I think they chose freebsd because it it _still_ driving the majority of hotmail, perhaps this is thier "FreeBSD version of Linux" See the link below:

http://www.cw360.com/article&rd=&i=&ard=110220&f v= 1

"Microsoft has built a FreeBSD version of Linux, but this is more of a publicity gig than a serious endeavour."

Re:Why FreeBSD, here's my opinion

[reaper20]

I would guess one reason is the old "We're ok with BSD, its the evil GPL software like Linux that we have problems with."

If you code FS, don't _ever_ look at the source

[lkaos]

I am absolutely positive that the licensing terms for the 'shared source' are going to involve some sort of extreme IP protection mechanism that will give MS unimaginable amount of power to prosecute anyone who they believe is violating their IP.

From now on, FS developers will have to make sure that anyone on their project has _not_ agreed to the MS shared source license. Kaffe has a similiar policy because of Sun's nasty license.

Windows Forms?

[Anonymous Coward]

A substantial part of the classes are Windows Forms. How do they plan to implement them on FreeBSD?

Re:Why FreeBSD, here's my opinion

[Snowfox]

I would guess one reason is the old "We're ok with BSD, its the evil GPL software like Linux that we have problems with."

Well, more importantly, this creates a convenient runtime binding mechanism for neutering GPL. If you're indirecting calls through the a mechanism such as this one, you can use all the GPL code you want and not have to share any source but the GPL-side adapters.

It's a short step from here to creating staged runtime hierarchy bindings so you can even extend the GPL code directly without sharing the source for your changes.

Re:Windows Forms?

[tb3]

They don't. Windows Forms is not included in the 'standard' they submitted to ECMA. Which makes their duplicity rather obvious. At least Sun tried with the Java Swing library, even if it doesn't work very well.

Muddying the Waters....

[zulux]

Microsoft is engaging in a tactic called "Muddying the Waters" - when your adversary has crystal clear goals and objectives, you can divert him by giving him extra goals and more interesting things to ponder. Any time spent away form the goals of Free Software is a win for Microsoft.

Remember that the sucuess of Linux is due to the GPL and not due to it's technical merrits. If technical merrit were all that mattated - we all would be running Be right now.

Linux and Free Software are winning becuase we are not playing Microoft's game of Shiny-Box-On-Retail-Shelf software. We are using the desruptive technology of the GPL. and Microsoft is now getting wise and is trying to play our game.

Don't let Balmer make you do his monkey dance.

There is an end-run around 'Non Commercial'!

[Jack William Bell]

Available for 'Non Commercial Use Only'? Hmm... But this is a runtime! This has some really interesting implications...

Let us suppose Rotor is fully compatible with the Windows CLI. I develop a commercial application for the Windows CLI. I also test the application for Rotor, but I don't ship the application packaged for it. Instead I ship the application packaged so that it simply expects a CLI runtime.

In my FAQ I mention that it was tested with Rotor and provide a pointer to some generic explanation for installing a CLI application to run with Rotor. My customers wanting to run the app on FreeBSD or Mac (or any future Rotor implementation) simply install the app as described and now have my application there.

Microsoft may have a case against this, but they probably do not have a case against me. And I doubt they would go after all of my customers.

Jack William Bell, who thinks this is a pretty unlikely scenario and is hoping Mono will make it moot.

Re:consistent and nothing new

[Anonymous Coward]

they can comercialize anything they want and lock out the orignials. Like winsock.

If Microsoft had produced a competing TCP/IP stack, and charged slightly less than Trumpet did for their Winsock, I could see your reasoning. It would be even worse if they'd engineered Windows to specifically not work with Winsock.

Instead, they just incorporated a TCP/IP stack into Windows, with dialup networking, for no additional charge. Plus, third party Winsocks continued to be usable.

I know, I know. Microsoft shouldn't improve their OS, they should just let it devolve into a soup of third-party addons. Linux advocates, who run an OS composed entirely of a big wad of third-party addons, should hold this sentiment dear.

Rotor intentions

[david_stutz]

[I'm the guy on the Rotor team who presented at this BOF.]

We absolutely welcome slashdot "community input." I'm pretty sure that a lot of slashdotters will be interested in taking a look at this implementation; it is a pretty fascinating piece of technology, both in terms of the abstract approach to virtualizing resources that the ECMA CLI uses, and in terms of the implementation choices that have been made.

Anyone who wants to better understand how the .NET Framework works will be interested. Likewise, anyone who wants to better understand Mono or PNET or the Microsoft "Compact Framework" will also be interested!

Many of the comments on this thread might be summarized as follows: why is Microsoft doing this? The answer is that we really want the ECMA standard to succeed (and that includes success for non-Microsoft CLI implementations!) and we also want to seed the use of the CLI over the long haul. The only way to do this is by participating in the community that moves computer languages and runtimes forward - we believe that many experimentally minded folk will find Rotor a great base from which to work.

Re:consistent and nothing new

[Anonymous Coward]

hmm? micro$oft can improve their OS all they want as long as they dont lock out competition. here's a counter example to your winsock example. stacker released its stac compression card and disk compression software for msdos 4.1 and later. M$ comes out with doublespace in dos 6.22 which is fine. stac users dont like doublespace which is a pile of shit and continue using stac. oopsy -- M$ engineered MSDOS 6.22 to be incompatible with stac causing slow disk corruption. a fact stac users took ages to figure out. and by the time anyone figured it out disks were corrupted and huge losses of data had already taken place.