Mobius – .NET runtime running on .NET Core | Hacker News Reader

Mobius – .NET runtime running on .NET Core

tooslowexception.com

156 pointspjmlp42 comments

You might find this project interesting OP[1]. The aim is to create a self-hosting CIL JIT/AOT for the purposes of an operating system. Ultimately you'd have an OS written in 100% C#.

It has got a good few years of history and a lone brave contributor who I'm sure would welcome some help with open arms.

[1]: https://github.com/mosa/MOSA-Project

I thought about doing something similar in university. But I used LLVM as the compiler backend: https://github.com/lostmsu/CodeBlock

Written in F# of course.

I've been wanting to make some .NET apps for our family's use (like a timer etc.) but don't know C# so I figured maybe I should just start off learning F# since I have a FP background. So is F# pretty much Rust but with GC? Or is it more like TypeScript -- in the sense that it's based on OCaml which maps nicely to JS (i.e. ReasonML) -- but also with sum types?

If all you are wanting to do is make desktop gui stuff for your family C# + Winforms is super easy to pick up.

Or perhaps skip it altogether.

Most of my “family” apps is just quick hacks in JavaScript. Simple to throw together, runs on everything with a browser, like the tv, and is easily published on anything serving static files, like github pages.

Edit: For some more hobby like projects C# works out quite nicely though. I’d say it’s probably easier to stick with the beaten path here if not seeing a particular advantage from a functional language. I hear F# is quite nice as far as a functional languages go though.

I've been wanting for a while a lightweight Electron alternative that doesn't use web views, just native APIs, and uses Lua instead. So it would be an .exe file that looks for a main.lua somewhere, and runs it, giving access to modules that wrap the Win32 API in high-level functionality. Then you could run a command that combines the .exe and the main.lua into a new .exe file that you can distribute. It would be super lightweight and wouldn't even need a compiler to be installed to be able to make tiny lightweight apps.

The nerd in me just saw a great application of a futamura projection. ;)

So something like LÖVE2D with wrapped Win32 APIs? That would be super cool, I wonder if anyone has done something like that.

I know there are Win32 Lua APIs. Maybe this is a 10 line windows app that just loads those in a host that loads main.lua?

Assuming the GP has equally zero knowledge of both, it would be better to start with WPF.

Rust isn't very FP, even if working with a borrow checker limits sharing, thus approaching the problem from a different angle, but with similar results as referential transparency.

And TypeScript doesn't have much in common with OCaml.

F# is similar with OCaml, yes, but it's missing some OCaml features such as functors and row polymorphism. It also uses .NET's OOP and introduces a couple of nice features of its own like type providers.

It's a cool language, especially if you want to target .NET

F# is 85% OCaml. IDE is probably better though. Also you get all the .NET libraries.

. . . kind of.

F# is OCaml minus the macro system, minus the higher-order module system, minus the OCaml object system, plus the .NET object system, plus a bunch of fun builtin features that nevertheless mostly just supply stuff that OCaml can do with macros, plus non-painful multithreading, plus a fairly different syntax.

They are both members of the ML family, but that tells you about as much about what they have in common as pointing out that C# and Objective-C are both members of the Algol family.

Actually, for UI stuff you might want to just do C#. UI designers work better there.

If you want to use F# to build GUIs, you should definitely check out Fabolous [1]. It uses Xamarin.Forms to render the widgets, and you get to write the application logic using the Elm architecture.

[1] https://github.com/fsprojects/Fabulous

It might be better to try C# first, if only because tooling as better, especially once you get to UI.

And C# has accumulated quite a few features that are traditionally considered "functional". For example, pattern matching: https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csh...

The big question, for me at least, is can this be used to containerize a .NET application without having to package a full Windows OS into the container?

This is just the .Net runtime most application will probably depend on the .net framework libraries so not really.

In case you weren’t yet aware, .NET Core runtime can be containerized on Linux. .NET Framework is the (mostly) Windows dependent runtime. Mono is the open / Microsoft supported translation of .NET Framework to Linux.

Right but converting a big application to .NET Core is hard. Is this project not sort of an emulator to allow a legacy .NET Windows app to run on .NET Core? I had better read TFA better.

I've never tried it, but from memory I think you can run .NET Framework under Wine, which presumably you could put in a container.

But honestly, I think your time would be better spent moving it to .NET Core. I've moved a few big apps, and while I wouldn't class it as "easy", it wasn't really that difficult, more time consuming that anything.

You're postponing the inevitable. .NET 5 is .NET Core.

Yes, but many legacy .Net apps were delivered without source-code, the original developer is not available, and now people like OP and me are looking to run this old crap (for paying customers) without having to maintain a dedicated Windows VM.

Even with source, it's still a big undertaking to convert to .NET Core but efdee is right, it's just postponing the inevitable. I'm sure we will go to .NET 5 soon enough.

Have you tried decompiling it? Telerik Just Decompile will decompile it back out to C#. It ultimately depends on agreement you had with the original developer as to whether it is legal or not.

Not necessarily. It really depends on your platform and 3rd party library usage scope. There also exist very helpful shims for accessing legacy .NET Framework functionality as long as you are running your .NET Core applications on windows:

https://www.nuget.org/packages/Microsoft.Windows.Compatibili...

The idea here being that you can quickly move to .NET Core using the compatibility shim, and then incrementally work your way off of it. .NET 5 will support the exact same concepts, so it still makes sense to engage this task if you want to get onto the new bandwagon.

If you try to do it in one big hit it will be hard but you don't have to do that. You can move it over piecemeal.

You can use multi-targeting to move parts of your code over to .NET Standard. So if you start with your base projects and move your way up, gradually your code will become compatible between .NET core and .NET Framework. This will help you remove any .NET Full Framework / Windows specific bits. Where you have to have things that are specific to each OS you can then just configure your DI so it will inject the Windows specific / Linux specific implementation.

For those that are not aware of multi-targeting here is a great article on it:

https://weblog.west-wind.com/posts/2017/Jun/22/MultiTargetin...

I used the multitargetting approach over the last year to convert most of my code to .NET Standard (about 50KLOC). The latest .NET Standard 2.0 and .NET Core 3.1 make it pretty easy. MS' previous attempts at multiplatforming were hit or miss, but they really seem to have finally gotten it right.

Part of what has made it so much easier is the new "SDK Style Project File Format". It makes manually editing the csproj file mostly easier than using the VS editor for the vast majority of tasks. Which, for better or worse, is necessary to get some of the latest features. Got example, you can enable most of the latest C# 8 features for .NET Framework (which officially is stuck at C# 7.2).

The old multiplatforming options I don't think anyone bothered with. It certainly much easier than before.

The hard part is exactly all those legacy APIs that are often Windows-specific. This is just a custom implementation of the CLR; it doesn't do anything about the libraries, so far as I can tell.

"containerize" is a very loaded/subjective term. In my experience, the best container-like boundary for .NET Core applications would be the process itself. AppDomains and related fanfare don't really exist anymore, and the process is the only common abstraction across all platforms that shares most of the same principles. It's always been the best grain to go along IMO.

I assume the author really means "run in a Linux context, without Windows". Otherwise, if you really just want to containerize and don't mind running an instance of Windows, you could use a Windows container.

If I read TFA correctly: Maybe in a couple of years, if a 100 devs jump on the project. The author is currently in the "Proof-of-concept" stage. Nevertheless an interesting project and write-up. Probably to late to run old legacy .Net Apps that -unfortunately- you "inherited" without source-code.

Lots of Linux images available @ https://hub.docker.com/_/microsoft-dotnet-core-aspnet/

Definitely useful for research. "What if the .NET CLR could do X" can be answered more quickly with code like this. I wonder if this could support something like runtime macros. Maybe you can do that anyway using Roslyn.

... so it's like running Wine on Windows NT 4.0?

No, it's an interpreter for CIL. Wine is mostly an implementation of the Windows API, not an interpreter or emulator of any kind.

They say it has a JIT, a just-in-time translator. Not an interpreter. Wine also has a translator that translates Windows application's calls to Win32 into calls to Linux API.

The comparison with Wine is not totally incorrect.

I think it's normal to include a JIT as a specialised form of interpreter.

CoreCLR, the .NET Core runtime, does not have an interpreter - it JIT compiles the bytecode immediately. Given Mobius is a .NET inspired project, it’s likely it will follow that approach as well.

JIT is a compiler - bytecode to native code. Wine is not a translator in that sense - it doesn't rewrite native code to change the APIs it calls. It just provides an implementation of those APIs, which may (or may not) ultimately invoke some POSIX or X API.

It might be an interesting perspective to think of almost any software library or framework as a kind of interpreter or translator from the layer above it to the layer below - e.g., a web browser is a translator from DOM constructs to native draw calls?

Reply on news.ycombinator.com