If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Wine-Mono Isn't Too Fit For .NET

02-04-2013, 05:20 PM

Phoronix: Wine-Mono Isn't Too Fit For .NET

Over the past few months there's been several Phoronix articles about Wine-Mono, a fork of Mono and a Win32 build of this open-source Microsoft .NET implementation for Wine. Wine-Mono can be used in place of Microsoft's official .NET framework when it's needed as a dependency for Windows programs running within Wine. Unfortunately, Wine-Mono doesn't always work out well...

Comment

Nearly every .Net(MSIL) calling routine in Wine installed applications or games using Mono, don't work, so it's a hate relationship. Then when you try .Net installs they fail. Other words Wine users are locked out of executing code that uses MSIL.

The mono team and someone from Wine, need to hash out why simple applications fail and repairing each bit so that they slowly build a functional engine.

Some scenarios:

* games are starting to have MSIL installers
* if you need to crack a game, some keygens and crackers are MSIL made (sometimes cracking a game is needed even when you own the title to get it working in Wine)

Comment

Mono is microsoft's patent trap and any sane distro stays well away from it.

Some wise words there. Never trust Microsoft.

Since Mono is open source and MSIL being standardised, you pretty much need not worry.

Having an intermediate language is a great scheme for computing as it's like assembly code without being tied to a CPU and its opcodes style. It is interoperable and fast. It should produce code faster than CPP.

Since the Linux realm is heavy on source compiling, the need for Mono isn't as strong as other platforms.

Comment

(...)
Having an intermediate language is a great scheme for computing as it's like assembly code without being tied to a CPU and its opcodes style. It is interoperable and fast. It should produce code faster than CPP.

Since the Linux realm is heavy on source compiling, the need for Mono isn't as strong as other platforms.

Even I'm a supporter of Mono as an idea, Mono most likely will produce code close to, but not faster than C++ (I mean optimized Mono vs optimized C++).

There are more reasons why:
- the backend default optimizer does not have powerful registry allocation in Mono (which in turn means that there will be a bit more round-trips to memory if a specific code will not fit into registries)
- if you play with optimization levels like -O3 -flto (if it works) it should give basically the same view for the C++ optimizer that Mono has, so it can give at least comparable code
- using LLVM as backend will mean that Mono can be on par with C++ (in specific math workloads) as LLVM has a very good registry allocator from version 3.0. There is a note though: the code generated by Mono has to be similar with the code of a C compiler gets (but Mono will have some extra checks many time along the way, you will have to pick -b in Mono's command line to remove bound checks)

Being all this said, I think that Mono (at least in AOT mode, meaning that most of components that make the software are compiled, not JIT-ed) give basically the same experience that you will have with a C++ code for most applications. This blog entry sumarizes why: http://pl.atyp.us/wordpress/index.ph...because-its-c/ (algorithm, IO, synchronizations, and other operations, if are not written thoughfully can be slower in C++ than a better written code in other languages).

Like 15 years ago it was really popular Delphi/VB, and the reason was that these applications gave 40% of the performance of C++ but removed all the hassle to write ugly visual code. C# is for me in the same category: it runs really fast, it is easy to program with, it has a GC with small pauses that can fit in a phone application, and in many cases there is minimal work to be done to work with UI, databases, xml, (and all others).

You can get a list of changes I've contributed to Mono using "git log --author='Vincent Povirk'" in the official Mono repo. It's not as big a list as I'd like, but it's bigger than the diff between Mono and wine-mono. If I commit something to my fork of mono it's either because I need it immediately (in which case I also submit it to them), or I don't think the change makes sense for them.

The mono team and someone from Wine, need to hash out why simple applications fail and repairing each bit so that they slowly build a functional engine.

I would say that simple applications usually work. Usually, if I have a copy of an application I can figure out why it fails.

All but the simplest of applications actually rely on a surprisingly large amount of functionality from the OS. When I think about things that way, it's amazing to me that Wine works as well as it does. The fact that Wine works so often is the result of many years of hard work by many people. Even though I say that Mono almost never works in the context of Wine, the amount that it is able to do even in that context is still amazing to me, and we would be much worse off right now if it weren't for years of hard work from people on the Mono project.

As I said in the talk, there is not a single problem that's affecting most Windows apps (though there are individual problems that, if solved, could help substantially). I've seen problems with obscure IL features used by Managed C++ (which was also used by Microsoft to develop XNA, and affects XNA apps), lack of a WPF implementation, limitations of Mono's COM support, bugs in Mono's Visual Basic class libraries, and bugs in Mono's winforms implementation. Some of these problems are very difficult, but some are easy problems that I've documented on Wine's Bugzilla. I've not yet put in the time to fix all of the easy ones, partly because I have other priorities (dictated by the fact that I work for CodeWeavers which is a real company that needs to make money) and partly because it seems like a waste of an opportunity for someone to learn Wine development.

As a rule, I don't work on keygens or cracks, so I don't know (or care) if the picture is somehow different for those.

Comment

You can get a list of changes I've contributed to Mono using "git log --author='Vincent Povirk'" in the official Mono repo. It's not as big a list as I'd like, but it's bigger than the diff between Mono and wine-mono. If I commit something to my fork of mono it's either because I need it immediately (in which case I also submit it to them), or I don't think the change makes sense for them.