Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Open Source Microsoft Software Technology

Microsoft Open Sources CoreCLR, the .NET Execution Engine 253

An anonymous reader writes: As part of Microsoft's continuing project to open source the .NET framework, the company has announced that CoreCLR, the execution engine for .NET Core, is now available on GitHub. CoreCLR handles things like garbage collection, compilation to machine code, and IL byte code loading. The .NET team said, "We have released the complete and up-to-date CoreCLR implementation, which includes RyuJIT, the .NET GC, native interop and many other .NET runtime components. ... We will be adding Linux and Mac implementations of platform-specific components over the next few months. We already have some Linux-specific code in .NET Core, but we're really just getting started on our ports. We wanted to open up the code first, so that we could all enjoy the cross-platform journey from the outset."
This discussion has been archived. No new comments can be posted.

Microsoft Open Sources CoreCLR, the .NET Execution Engine

Comments Filter:
  • by Sklivvz ( 167003 ) <.marco.cecconi. .at. .gmail.com.> on Wednesday February 04, 2015 @05:23AM (#48977941) Homepage Journal

    Because, you know, open sourcing by the devil has to be evil! :-)

    In all seriousness though, does this make .NET more open than Java? In other words, RMS-acceptable?

    • Because, you know, open sourcing by the devil has to be evil! :-)

      Hey, better late than never ... worked out with that whole Internet thing, huh? :)

    • Re: (Score:3, Insightful)

      by Goaway ( 82658 )

      If it's MIT licensed it's probably a bit too open for him.

    • If it is the devil that is open sourcing it, by definition it has to be evil. Whether Microsoft is the devil is debatable though.

  • ....but I didn't know I live in hell. No flying pigs or raining frogs though, so maybe we're good.

  • So, I will be able to run pure .NET applications on Linux desktop? Interesting
    • by silviuc ( 676999 ) on Wednesday February 04, 2015 @05:36AM (#48977997) Homepage
      If they're CLI, yeah, you'll be able to. You could already do that using mono. The problem is GUI applications that use WinForms which is not open-source and probably won't be for a looong time.
      MS likes Linux as a server, on Azure.
      • It looks like Mono has support for WinForms [mono-project.com]. I've never used it though, and usually used GTK# for GUI development on Linux.

        • by HyperQuantum ( 1032422 ) on Wednesday February 04, 2015 @06:57AM (#48978277) Homepage

          The problem is not WinForms, but WPF [mono-project.com]. An increasing amount of applications use WPF because WinForms is considered 'deprecated' by Microsoft and people are encouraged to use WPF instead, which is the new 'hot stuff'.

          • Re: (Score:2, Interesting)

            by gbjbaanb ( 229885 )

            Sorry no, WPF is the new Silverlight. Microsoft wants you to use HTML5+js (which isn;t much different from XAML+c# anyway).

            They are pushing Cordova now, the Visual Studio addin that gives you support for that can do you cross platform GUIs (and on phone) and they are saying its the best way to create "Metro" apps. Expect more of this rather than WPF that is crippled partly by poor performance and partly by infghting between the Microsoft teams.

            • by fractalus ( 322043 ) on Wednesday February 04, 2015 @08:13AM (#48978593) Homepage

              This is why I don't like developing for Microsoft's stack. They seem to want to throw everything out every few years and start over.

              Then again, it seems like the web business is like that, too. Damn. Doesn't anyone write non-disposable code any more?

              • by Dutch Gun ( 899105 ) on Wednesday February 04, 2015 @09:15AM (#48979049)

                Keep in mind that, even with new APIs introduced, the old stacks still continue working just fine. WinForms or WPF apps will still run on Windows desktop machines decades from now, just like native Windows applications are still using Windows API calls written decades ago.

                Also, despite rumors to the contrary, WPF is still being actively developed [msdn.com], although it's probably fair to say it's "peaked" as a technology, and is now transitioning into a maintenance mode. I'd have no qualms about creating a new WPF project tomorrow - so long as you know you're only targeting the Windows desktop. There are benefits to using a mature technology, and WPF is pretty mature at this point.

                You really only need to use the new stack (WinRT) if you're planning to do cross-platform stuff across the entire Windows ecosystem (Metro/Surface/Mobile).

              • This is why I don't like developing for Microsoft's stack. They seem to want to throw everything out every few years and start over.

                Not that different from the Java FOSS cornucopia. And in many ways, it is better than the design-by-committee-slow-as-molasses thing we have with JEE and the JCP.

                Then again, it seems like the web business is like that, too.

                A lot of it is ego and developers OCD/fixation with trying new technical things (as opposed to solving business problems with economical, yet maintainable solutions.)

                OTH, a lot of the churn is due to external pressures of competition. You put something on the web, someone is already competing with you.

                Then you have catch up at worst, or out-in

              • by Shados ( 741919 )

                Congratulations, you described the software engineering world in general. Tried JavaScript, Ruby or the JVM world lately?

                You -may- be ok with Python, i guess. But even that depends on what version you're looking at.

              • by Nemyst ( 1383049 )
                I disagree. They saw that their technology was outdated and, instead of dragging it for years as a giant ball and chain, they started from scratch, for the better. WinForms was basically the Swing of the .NET world, but with a much better visual designer. All the UI was built into the code as objects and the auto-designer would often make a mess of it, while building it manually was a complete nightmare.

                WPF, in contrast, completely rebuilds the software stack in favor of a more cleanly separated MVC-ish a
              • Comment removed based on user account deletion
              • by msobkow ( 48369 )

                Which is nothing like Sun switch from AWT to JFC, or Oracle switching from JFC to whatever they're calling the GUI framework-de-jour.

              • I do... but then my customers are public sector (police, EMS) who can;t afford to keep replacing their systems every few years.

                This is why I advocate multiple tier applications, like the MVC boys but without their "all-in-one project" mentality. Then you can write your server side stuff in a mature, reliable language and give some kids an API that they can use to build flashy GUIs in flash or javascript or whatever fashionable toy they like this month.

                And, strangely enough, everybody is happy with this appr

              • Then again, it seems like the web business is like that, too. Damn. Doesn't anyone write non-disposable code any more?

                It's astonishing to see every thread is controlled by SystemD.

          • Re: (Score:2, Insightful)

            by Anonymous Coward

            WinForms is not "deprecated". They merely introduced what they thought would be its replacement (WPF). The replacement was inadequate because:
            - It was only marginally compatible with existing WinForms code
            - It was radically different and required scaling a very steep learning curve, which is detrimental to development deadlines. This slowed its adoption drastically.
            - It didn't offer anything truly useful that couldn't be done with WinForms and a lot of glue code (developed decades ago, and is now battle-har

          • by Zalbik ( 308903 )

            WinForms is considered 'deprecated' by Microsoft

            No, it really isn't. A substantial segment of the community assumed it would be deprecated when MS started heavily pushing WPF. Given that WPF has been around for 8 years now, it doesn't appear to be the "WinForms"-killer some thought it would be.

            That being said, WinForms all but officially in "maintenance-only" mode. I would be seriously surprised to see new features. However, this is different than being deprecated.

            There are signs that WPF is also he

        • I have, on a fairly simple .NET app. Worked fine. But I can't claim exhaustive testing...

      • by PRMan ( 959735 ) on Wednesday February 04, 2015 @07:01AM (#48978301)
        WinForms has worked fine on Linux for a long time. WinForms in Mono [github.com]. Even better if you declare a folder named "C:" and then declare 5-6 folders named "Program Files", "Program Files (x86)", "Users", "AppData", etc. under that. If you declare the right folder scheme, a large percentage of Windows applications will run perfectly on Mono as is.
  • ... when I see a working fork in the wild. Like mysql mariadb. When I see that ppl or companies can do that, I will believe it is open source. Interesting times ahead :-)
  • Comment removed based on user account deletion
    • Re: (Score:3, Insightful)

      by Virtucon ( 127420 )

      Or they stop trying to license patents they hold on technologies that Linux uses. [blogspot.com] That would be a great gift for FOSS.

      • Why would MS want to gift anything to FOSS as a whole? This isn't a case of joining one huge orgy, you can participate in open source in very select ways and areas without ever intending to support the entirety of the movement.

  • by Virtucon ( 127420 ) on Wednesday February 04, 2015 @06:30AM (#48978191)

    Xamarian Mono [wikipedia.org] or it's predecessor Ximian Mono. This is both a good and bad thing because while they're releasing the code, why aren't they working with Xamarian since they've already got a cross platform .NET environment? Or is this the old Microsoft with the Embrace, Extend, Eradicate mentality we're seeing here?

    I've used Mono for a long time and while it doesn't have all the frameworks, it's great if you want to C# code and go cross platform. It's still .NET 4 compatible and things like WPF aren't in there so YMMV

    • Re:Too Late Really (Score:5, Informative)

      by Richard_at_work ( 517087 ) on Wednesday February 04, 2015 @06:47AM (#48978237)

      The .Net CoreCLR is a rewrite of the .Net CLR from the ground up to support the specifics of the vNext project, so the Xamarian project isn't a good fit for this either as they would still need to start from scratch. Xamarian will still cover the entire CLR as it currently does (with some exceptions to the base class libraries), while the CoreCLR platform is a hugely stripped down and optimised runtime designed to be deployed with individual apps.

      For example, at the moment you deploy a .Net web app to IIS and it uses the .Net runtime installed server wide (in the GAC). With Mono, you deploy it to Apache and tell Apache to use the Mono runtime - but that is still Apache wide, so you can't run a second version of Mono without running a second instance of Apache configured specifically.

      In vNext, you deploy your web app and it comes with everything it needs to run - application code, CLR, Katana (or other OWIN implementation) and even a choice of web servers which are not dependent on the target server. This means you can run different versions of .Net for different applications, and can upgrade some without affecting others - because upgrading .Net is now as simple as redeploying the site. It also means no heavy dependency on IIS or Apache.

      Thats why its not an adaptation of Xamarian, because the two are quite different - however, at the recent NDC where they announced all this, they did announce much closer ties with Xamarian to work on Mono as the full implementation of .Net cross platform, so Xamarian aren't being left out to dry.

    • This is both a good and bad thing because while they're releasing the code, why aren't they working with Xamarian since they've already got a cross platform .NET environment?

      There's nothing about about competition in OSS. If the license is truly open then they'll be able to use any bits of the code they want. So, is it?

    • Re:Too Late Really (Score:4, Informative)

      by dissy ( 172727 ) on Wednesday February 04, 2015 @07:18AM (#48978365)

      Xamarian Mono or it's predecessor Ximian Mono. This is both a good and bad thing because while they're releasing the code, why aren't they working with Xamarian since they've already got a cross platform .NET environment?

      An interview with Miguel De Icaza (creator of Mono and co-founder of Xamarin) on that very question:
      Microsoft .NET released from its Windows chains... but what ABOUT MONO? [theregister.co.uk]

    • by AmiMoJo ( 196126 ) *

      Or, you know, maybe the first step in co-operating is to release what they have and then see what they can share? Or perhaps they want there to be multiple .NET CLRs available to provide some diversity.

      Maybe it is part of an evil plot, but it's a bit early to leap to that conclusion.

  • by Dan East ( 318230 ) on Wednesday February 04, 2015 @07:37AM (#48978459) Journal

    Just think if MS would have done this over a decade ago when they released C# / .NET. It could have nearly replaced Java. I could see 3rd party "standards" created for widgets that would be cross-platform (like Swing, etc, for Java), that people could use to create their cross-platform windowed GUI type apps. The formal Windows APIs would be used for people wanting to create full blown Windows-only apps. However all the core functionality (non-gui stuff) would be cross-platform and if written properly could have driven both the "Swing"-ish community created GUI, as well as the official Windows GUI stuff.

    • by Shados ( 741919 )

      The thing is, let say they do that. Then what. Developing something like that is hard, takes really smart (read: command a high salary) people, tons of project management resources, etc. Thats a lot of dough.

      You get some good will and dominate the market, but that won't repay anything. Almost anyone still using Windows who doesn't do it for legacy reasons (that is, people who have been using Windows and can't go through the trouble of switching) on the server, does so because of .NET.

      So you'd have .NET all

  • In other news, Oracle has announced that they're working on a new version of Java.

    Dubbed vNExT, it's supposed to provide a much faster VM than the classic JVM,

    Unfortunately, to take advantage of it, you have to recompile your Java code with the new "Joslyn" compiler, which isn't quite done yet.

  • by frank_adrian314159 ( 469671 ) on Wednesday February 04, 2015 @11:03AM (#48980001) Homepage

    It's relatively nice as far as VMs go, better designed than the JVM. This was a piece of good engineering work from Microsoft and I'm glad they're opening it. Welcome to the new world, MS guys. You don't seem to be acting quite so black and white anymore. Good on you.

    And to the naysayers... well, it's a start. Be kind.

  • by ilsaloving ( 1534307 ) on Thursday February 05, 2015 @10:27AM (#48988911)

    Does this mean Microsoft has developed cancer?

    Seriously, while recent moves in this regard have been good, only a fool would ignore history. Microsoft, for as long as it has existed, has done countless morally dubious things in order to maintain control. The history is all right there for the googling. Just because they do a couple Good(tm) things doesn't magically mean they have suddenly realized the errors of their ways and are doing a 180. You can't erase ~40 years of assholry.

    Based on the moves Microsoft has done lately, I will move my needle from "completely distrust" to "MAYBE it's not a trap" but still nowhere near the realm of "trustworthy"

Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P.D. Ouspensky

Working...