Results 1 to 9 of 9

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

  1. #1
    Join Date
    Jan 2007
    Posts
    14,375

    Default Wine-Mono Isn't Too Fit For .NET

    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...

    http://www.phoronix.com/vr.php?view=MTI5MjQ

  2. #2
    Join Date
    Dec 2011
    Posts
    2,008

    Default Upstreams

    Too bad hes changes don't get merged back in upstreams Mono.

  3. #3
    Join Date
    Jan 2011
    Posts
    457

    Default

    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)

  4. #4
    Join Date
    Jan 2013
    Posts
    1,446

    Default

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

  5. #5
    Join Date
    Jan 2011
    Posts
    457

    Default

    Quote Originally Posted by dee. View Post
    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.

  6. #6
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    398

    Default

    Quote Originally Posted by e8hffff View Post
    (...)
    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).

  7. #7
    Join Date
    Feb 2013
    Posts
    2

    Default

    Yay, this article looks accurate, though a bit less hopeful in tone than I had hoped to convey.

    Quote Originally Posted by uid313 View Post
    Too bad hes changes don't get merged back in upstreams Mono.
    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.

    Quote Originally Posted by e8hffff View Post
    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.

    Quote Originally Posted by dee. View Post
    Mono is microsoft's patent trap and any sane distro stays well away from it.
    I never understood the assertion that Mono is somehow riskier wrt patents than Wine.

  8. #8
    Join Date
    Dec 2011
    Posts
    2,008

    Default

    Quote Originally Posted by madewokherd View Post
    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.
    Does Mono accept your patches?
    Does Wine accept your patches?

  9. #9
    Join Date
    Feb 2013
    Posts
    2

    Default

    Quote Originally Posted by uid313 View Post
    Does Mono accept your patches?
    Does Wine accept your patches?
    Both projects have accepted patches from me.

    I'll make this easier. I just signed up for ohloh, and here's my profile: https://www.ohloh.net/accounts/madewokherd

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •