Follow Slashdot stories on Twitter


Forgot your password?

Mono Ships ASP.NET server 407

Miguel de Icaza writes "We have just released the new version of Mono the new version includes a working version of ASP.NET. The release includes a sample web server that "hosts" the ASP.NET runtime (it can be hosted anywhere, for instance in Apache, with mod_haydn). The web features of ASP.NET would not be very useful without the support of a backing database. The new version of Mono includes database providers for Oracle, MS SQL, Sybase, ODBC, OleDB, Gnome Data Access, SqLite, MySQL and of course, Postgres. The C# compiler is now 37% faster due to some nice optimizations on the JIT engine and in our class libraries. You can use it to develop GUI applications using Gtk#. Screenshots for mPhoto and the GUI debugger (which can debug both JITed apps and native applications). "
This discussion has been archived. No new comments can be posted.

Mono Ships ASP.NET server

Comments Filter:
  • bleh. (Score:2, Funny)

    Mono? I don't feel well.
    • Re:bleh. (Score:2, Funny)

      by Anonymous Coward
  • by MagPulse ( 316 ) on Tuesday December 10, 2002 @02:34AM (#4851955)
    It's a weird experience to run the same exe in Windows and Linux with the .NET or Mono runtimes. When Mono supports WinForms (by translating them to Gtk#), so GUI apps written with Visual Studio .NET's GUI builder work on Linux, that will be significant.
    • by miguel ( 7116 ) on Tuesday December 10, 2002 @02:46AM (#4852021) Homepage
      People are working hard to get Windows.Forms to work. We initially planned to have a Gtk backend, but turns out that Windows.Forms sadly exposes bits from the Win32 API that would be very hard to emulate (or at least terribly painful to debug).

      The major problem is the Control.Wndproc method which effectively allows any control to hook up to the Windows message system. This is not a problem for most applications, but many special "effects" in widgets are created by hooking up here and processing the messages here.

      To avoid emulating Win32 ourselves, we chose to use WineLib as the foundation for implementing Windows.Forms. Later to match the native look of the linux desktop we will provide the Wine team with patches to use the Gtk rendering engine on Unix and the Cocoa rendering engine on MacOS.

      Far from ideal, but its the only way we can guarantee good portability with minimal pain to the developers.

      There is now a new momentum to get this work moving, and given that it is possible today to test the various controls in Windows against the real implementation, you do not have to fight the incomplete Windows.Forms code before testing your code.

      More details: (for the Windows.Forms plans and mailing lists)

      • Miguel,

        Could you explain why, when I install Ximian Gnome, your software overwrites all the shortcuts in the "foot" menu and replaces them with your own offerings?

        This, frankly, sucks. Folks trying Linux are just getting familiar with their systems and the programs that are typically installed. Then they get the bright idea to install Ximian because it looks "friendly", and you come along and take away all their programs.

        Keep in mind that most folks won't know how to get those shortcuts back (if it is even possible). Your software is advertised as being ideal for newbies, yet in practice, it is actually hostile. This is typical of open source software, in that your own self-serving interests (promoting Ximian) are placed above that of the user.

        In short your software is stupid.

        Thank you.
        • by miguel ( 7116 ) on Tuesday December 10, 2002 @04:01AM (#4852342) Homepage
          Yes, I can explain.

          The menu reorganization was actually something that we took quite seriously. The issue that we were facing was that the contents of the menus on the default configuration of Gnome was hard to use, and the organization was the remainings of the work that had been done many years before.

          So we actually conducted usability tests on real users to try out Gnome, and perform a number of tasks. We observed them, we interviewed them, and we made changes to the software to reflect the needs of users.

          Our intention is to allow Linux to be used as a desktop solution.

          We tried our best to make it easy for newcomers, and am sorry to hear that you disagree. But at least you could use this experience to advise new users: depending on their needs maybe Ximian is right for them, or maybe not.

          Anyways, you can file a bug report against the problems that you found on, they might be worth following up.

          • by Anonymous Coward
            Would it be possible for the Gnome people to consider the needs of people who aren't newcomers occasionally? It's distressing when functionality is removed because it might confuse newbies. I installed RH 8.0 recently and was surprised at how bad the new window manager and panel are compared with the Gnome 1.x versions. I really don't want a huge panel all the way across the bottom of the screen when I really only use it for launching apps, but I am no longer allowed to have a smaller centered one that hides when I don't use it. I don't want little animated boxes when I minimize a window, but there's no way to turn them off that I've found; and why is there a seperate fonts preference box but no WM control box. Why can't I change that stupid hat icon to something else by right-clicking on it? Why can't I access most of the (actually readable) bitmap fonts that come with X? Why do I have to put up with this shit just because I want to get the twenty-year-old version of Python off of my RH 7.3 setup?!?!
          • I pay for Ximian Express as a way of supporting Evolution. When Ximian first arrived you had to download 100Mb to get it started.

            I did file a bug report on the conversion of the menus and the fact that on Red Hat 7.X Ximian killed the KDE menus when using a Gnome desktop.

            The feedback I got was to create a link to another directory in /etc

            This I do not think is suitable for a newbie. I think that it is also terrible to seriously damage the KDE menu structure in all versions of one of the biggest distributions.

            I had seriously considered at the time to stop making payments and would have asked my girlfriend to stop too; however I saw the funding of Evolution as more important so we switched to Mozilla and left the payments running.

            Still not happy :-)
      • by IamTheRealMike ( 537420 ) on Tuesday December 10, 2002 @05:30AM (#4852643)
        To avoid emulating Win32 ourselves, we chose to use WineLib as the foundation for implementing Windows.Forms. Later to match the native look of the linux desktop we will provide the Wine team with patches to use the Gtk rendering engine on Unix and the Cocoa rendering engine on MacOS.

        Hmmm. Considering the amount of effort that was required to make WineLib work correctly on Linux/PPC, are you seriously planning the totally enormous investment of resources it'd take to port Wine to MacOS as well? Considering the primary motivations seem to be to improve GNOME development tools and increase Windows compatability, is the MacOS port just a throwaway comment or are there serious plans?

        Only porting the core windowing and widget library would probably cut down the amount of work involved, but for instance Wine is heavily dependanct upon X11 currently....

      • by karlm ( 158591 )
        This is oftopic for this thread, but Miguel is defianetely one of the people to ask:

        Microsoft claims that the CLR bytecode is designd for JIT. Java bytecode was definately originally designed to maximize portability of interpreters (as in there are JVMs for 8-bit microprocessors and 64-bit "big iron") rather than for optimal recompilation to native code.

        To what extent is this true? Please tell us about features in the bytecode or the class file format that are optimized for efficient recompilation on the fly. I've read Ken Thompson's paper at Bell labs about the design of the DIS virtual machine. It would seem that a stack-based virtual machine is much less suitable for JITs than a memory based virtual machine. Cam you refute this, particualrly on non-register-starved platforms (PPC, ARM, Itanium)? Granted, memory machines much more complicated in concept than stack machines. However,for optimum register allocation in the native code, you need to basiclly undo the stack machine's register allocation (to two GP registers, the top of the stack) before doing register allocation, while memory machine bytecode is basically ready for register allocation with little preprocessing.

        You must have some gripes about MSs VM design. What are the main ones? What about the VM imposing C#s object model at the "hardware" level instead of using constructs written in bytecode and using privledged VM modes (analogous to privledged CPU instructions on a real machine, but perhaps much higher-level instructions) to enforce security restrictions? (This seems to be one of the main gripes of enthusiasts of non-ALGOL-descended languages on the .NET platform.)

        While you're at it, can you point to features that indicate MS really wanted a VM that worked elegantly with languages very unlike C#? I've heard that a main deterant to Stackless patches being merged into the main Python distribution is the changes necessary are very ugly to do in the JVM and would probably cause a major split with the Jython people. Would it be easy to get efficient handling of tail-recursion and efficient implementations of Stackless Python? How badlymangled internally are Perl.NET and Python.NET?

        Thanks for all of your hard work, and good luck in the future.

  • That's nice (Score:2, Interesting)

    by jonabbey ( 2498 )

    Mono is some great stuff, but it's going to take some time before .NET matches up with J2EE on Windows, let alone on the UNIX platforms.

    Gtk# is more interesting, I think.

    • Re:That's nice (Score:4, Insightful)

      by Anonymous Coward on Tuesday December 10, 2002 @02:40AM (#4851982)
      .NET Doesn't need to match up with J2EE in terms of features or performance, all that will matter will be whether Microsoft's marketing department can outspend Sun/IBM/Bea.

      All signs point to yes.
    • Re:That's nice (Score:2, Flamebait)

      by g4dget ( 579145 )
      before .NET matches up with J2EE on Windows,

      J2EE is a mess. Whether .NET matches up with it or not doesn't matter.

  • I don't see anything about a port for Darwin/MacOS X on the Mono web site. A full Aqua-# project would of course be a lot more work, but it would be fun to see it started in console mode or X-windows.

    Has anyone tried building Mono on MacOS?
    • by miguel ( 7116 ) on Tuesday December 10, 2002 @02:51AM (#4852050) Homepage
      Mono today works on LinuxPPC in interpreted mode, but does not work on MacOS X since the calling conventions are not the same.

      We started work three months ago on a new JIT engine whose main aim was portability (although the current JIT can be ported, most optimizations and coarse-opcodes had to be reimplemented over and over). The new JIT engine design has two intermediate level representations: a higher level one, and a low-level that can be as precise as required for a target CPU. The funny thing is that the new JIT is actually faster JITing code than the current JIT even with the added layer.

      The lower-level layer is actually something we are very proud of, Paolo architected a register allocator and instruction scheduler at the same stage, and we are using the PowerPC on MacOS X as the second platform to target to guarantee this time that the JIT is actually easy to port.

      We are hoping to release the new JIT engine in February/March.
      • Miguel. Congratulations on this milestone, I honestly doubted it and I'm now eating my words!

        Now, backpat asside, how will using winelibs for the winforms stuff impact on the LinuxPPC & alpha stuff (etc)... Can this be worked around... It'd sure be nice to run this on those crazy little powermac penguin boxen I got bangin' around my workplace.
        (I'm picturing here running borlands eventual apps on nutty old macs!)
  • Yay Mono team (Score:2, Insightful)

    by litui ( 231192 )
    I think this is terrific. I know very little about the fine details of coding for .NET, but I understand the significance of this project to the community of open source and non-windows users. Good job folks. Keep it up. =)
    • Re:Yay Mono team (Score:5, Interesting)

      by phorm ( 591458 ) on Tuesday December 10, 2002 @03:18AM (#4852177) Journal
      Good thing a:

      If we can get a better "forms" implementation on 'nix (windows-like without windows bugs), that would be awesome

      Secondly, but verrry important to those who do webhosting, clients requesting ASP pages would be able to run on 'nix servers, no longer requiring special windows dedicated hosts. For those who prefer 'nix servers, and many hosts do, running a windows server in the bunch is a pain in the butt!

      If this actually pulls through, I will be amoung many who are very, very impressed.
      • Re:Yay Mono team (Score:5, Informative)

        by jaavaaguru ( 261551 ) on Tuesday December 10, 2002 @10:15AM (#4853973) Homepage
        If we can get a better "forms" implementation on 'nix (windows-like without windows bugs), that would be awesome

        GTK+'s "forms implementation" is more advanced than Windows's. When you design a form, you can specify the size of cetain controls, and let GTK work out the sizes of other controls automatically on the fly. This gets round the problem that you see on Windows where if someone changes their display preferences to use "Large fonts", some text doesn't fit within the fixed sized label that the form has. With the GTK model, the label and other controls around it would resize automatically so the text fits in perfectly.

        Also, you can specify how controls on a form should be a aligned, and the alignment it handled by GTK, so you don't have to place controls on the exact pixel you want them to appear on (which is related the the previous problem). Yes, I know you can "snap to grid", but that still messes up with non-standard sized controls and in the scenario mentioned above with large fonts. I could just say "It's similar to the way Java handles GUI design", but I'd see all the Windows GUI designers respond with "but Java's UI looks horrible". On a system running only Gnome or similar, GTK is what all programs use, so they all look the same - none of this horrible inconsistency you see on Windows. GTK handles the themes or skins, so if the user doesn't like the look of your app, they can change the theme, and all apps still look the same as eachother. I know XP can do that, but dev tools on XP won't let you design a form in a GUI point 'n' click environment that follows GTK's ideas of automatically placing and aligning controls on the fly.

        As someone who's spent a bit of time creating programs with user interfaces in MFC, Java and GTK, that is my opinion. Now, do you still think that Windows has a better "forms implementation" ?
  • Bravo! (Score:2, Insightful)

    by telstar ( 236404 )
    Further proof that more is accomplished through innovation than through litigation.
    • Re:Bravo! (Score:2, Insightful)

      by AlXtreme ( 223728 )
      I would call it immitation, not innovation. But then again, 99% of all innovations are just immitating ones that someone else already had thought up.

      I hope for Miguel and the rest that Mono works out nicely, but imo it's just a workaround, and not a solution, to the evil empire (if ya can't beat em, don't join them, just hit harder ;o)
    • by Otis_INF ( 130595 ) on Tuesday December 10, 2002 @05:31AM (#4852648) Homepage
      Mono implements a piece of technology offered by Microsoft. There is no innovation there, at least not on the Mono part. Nothing wrong with that, but please, stop briinging the 'innovation' term into the discussion, since Mono is not about innovation.

      It CAN be about innovation by implementing generics into the Mono runtime before MS does this (MS will release the updated 2.0 .NET when Yukon (SQLServer 2003) comes out, late 2003, which will have generics support). However I don't see this happen soon.
  • by NZheretic ( 23872 ) on Tuesday December 10, 2002 @02:42AM (#4852001) Homepage Journal
    Microsoft's CEOs have made it "patently" clear [] that they intend to restrict competing .Net implementations by cultivating Microsoft's patents, such as United States Patent Application #20020059425 "Distributed computing services platform" [] [] which covers the design and inter-operation of .NET based implementations.
    Although there is prior art examples of individual technologies such as the JVM etc, Microsoft patents such as the one mentioned, define and claim the interoperation of the components, in such a way that any re-implementations will be sure to be covered by the patents. This remains true even for the Microsoft specs submited to standard

    In comparison, Sun has granted the Apache and all open source developers FULL access to the specs, test kits and granted the full rights to develop competing products under the JSPA [] . Sun has also fully pened up the Java development standards process under the new Java Community Process (JCP) []. Even to the point of granting full open source re-implentations of J2EE such as JBoss []...

    JBoss received the green light last week, after Sun told ComputerWire that it would allow all of the APIs contained in J2EE 1.4 to be open sourced. Fleury had expressed concern that certain critical APIs, including Enterprise Java Beans (EJB) 2.1, would be not be made available to open source organizations.

    However, Java Community Process director Onno Kluyt said: "Sun's plan with 1.4 is that although it started before JCP 2.5, by the time it ships it will allow the creation of independent implementations. I don't think the APIs are that interesting, because the license that sits on top of J2EE will allow that [independent implementations]".

    There those that claim that .NET is open to re-implementation, but until Microsoft make a simliar public legal declaration to Sun's JSPA, any .NET reimplementation represents a pending legal mindfield.

    • IANAL, but don't you lose your rights to a patent if you don't aggressively defend it?

      Microsoft has publicly admitted their knowledge of Mono through publications such as MSDN and other places. They can't claim they haven't known about Mono, known its aims or known anything about what the project was capable of. I don't see how they can pursue a patent claim now - 12 months later - if my first paragraph is true.
    • Actually MS has a spec' for non-Windows versions of .NET. This is what is to be used for the FreeBSD and Mac versions of .Net that MS is backing alreay. It is a subset of the CLR that needs to be supported.

    • by g4dget ( 579145 ) on Tuesday December 10, 2002 @04:53AM (#4852517)
      In comparison, Sun has granted the Apache and all open source developers FULL access to the specs, test kits and granted the full rights to develop competing products under the JSPA

      There are so many things wrong with that that it's hard to know where to begin:

      • A bunch of web pages do not constitute a legally binding contract.
      • It is rather unclear what exactly the extent is to which these promises would open up Java.
      • For an open language standard, it is insufficient only to open up the standard to open source implementations.

      Sun has renegged on several previous promises regarding Java: they failed to go through with standardization, twice, and they failed to deliver lots of functionality that they promised (e.g., value classes).

      If Sun wanted to open up Java, they would go through a standardization process, identify all the relevant patents in question, and make a legally binding commitment as part of the standards process. Instead, we are just getting fuzzy promises while Sun keeps filing Java-related patents.

      As far as I'm concerned, both Sun and Microsoft are greedy and untrustworthy, and the open source community would be foolish to throw their lot in with either company.

      • by e_n_d_o ( 150968 ) on Tuesday December 10, 2002 @05:18AM (#4852611)
        A bunch of web pages do not constitute a legally binding contract.

        IANAL, but in the case of Sun making these statements regarding open source Java and J2EE implementations, I believe those who make investments (both in time and/or money) do have a fairly solid guarantee that Sun will be held accountable for these statements even if they decide to "go back on their word."

        I'm very curious to know whether these pages could constitute a legal contract. They have consideration, in that Sun receives more developers and more implementations of its frameworks in exchange for more liberal licensing. The pages makes an offer that is accepted by parties developing implementations. The documents are official and exist for the purpose of informing developers of their rights.

        As far as I'm concerned, both Sun and Microsoft are greedy and untrustworthy, and the open source community would be foolish to throw their lot in with either company.

        I don't think any open-source developer in his right mind would "throw their lot in with either company." However, open-source developers are more than willing to support open technologies, even if they are backed by big mean corporations whose executives vacation at retreats where they club baby seals, if they know they are developing on an open platform and they can develop software to provide benefit to themselves and others.
      • by bwt ( 68845 ) on Tuesday December 10, 2002 @10:53AM (#4854297) Homepage
        * A bunch of web pages do not constitute a legally binding contract.

        That is certainly true. A contract is a quid-pro-quot between two parties where each side assents to give up some form of consideration to the other.

        On the other hand, patents and copyrights do not require a contract to use -- they only require a licence. A licence is a unilateral grant of permission. Any unambiguous statement granting permission suffices, so while you are correct that their grant is not a contract, it is a licence and your point is offbase.
      • You allude to Java needing a standards process - have you read or looked at any of the Java Community Process stuff? What is your problem with a system that lets companies and individuals besides Sun propose and comment on enhancements and additions to Java?
    • by g4dget ( 579145 ) on Tuesday December 10, 2002 @05:05AM (#4852562)
      All the Microsoft patents that have been identified as relating to C#/CLR so far are irrelevant. For example, the patent you reference has no bearing on the Mono project; if it applies to anything, it applies as much to Java and C++ programs.

      Sun's patents, if anything, look much more worrisome. For example, patent 6,477,702 [] patents the basic Java bytecode architecture and can be used by Sun to shut down any competing implementation. Furthermore, despite lots of cheery announcements, there is no indication that Sun has made a legally binding commitment to license this patent freely for open source implementations, let alone competing commercial implementations. The way it looks to me is that Sun is just stringing the community along with promises, and they will change their tune when they feel that they have established a secure enough market position. Sun has broken lots of Java-related promises; they are not to be trusted either.

    • by Anonymous Coward on Tuesday December 10, 2002 @09:02AM (#4853436)
      This guy is 100% correct.

      I talked to my high school buddy who was a patent attorney, but who quit the business because he hated the whole business of IP law because he was morally against it.

      I asked him what could happen, and theoretically, depending on the strength of the patents, Microsoft could sit back and wait for Mono to be developed, wait until a critical mass of applications gets developed on it, and then start charging royalties to anyone using that technology.

      Unless someone clarifies the legal status of Mono in regards to Microsoft's patents, this is 100% definitely the situation that will occur.

      Think about it, it is exactly what Rambus tried to do with SDRAM. Microsoft is a business and looks to Linux as a major threat. It is a jackpot for Microsoft in two ways:

      1) They get the Open Source schmucks to do their work for them
      2) Once a bunch of businesses have implemented their business on .NET/Mono, Microsoft turns around a sues them for royalties.

      We need to get a legal clarification of Mono before any real development starts occuring. My guess is that it is stepping on a whole shitload of Microsoft patents, and it is the onus of the implementors (ie. Ximian) to make sure that they develop around those patents, or 1) be prepared to try to quash the patents or 2) pay whatever royalties Microsoft charges.
  • by MAXOMENOS ( 9802 ) <maxomai@ g m> on Tuesday December 10, 2002 @02:51AM (#4852045) Homepage that this version of Mono also comes with Mono Basic. Just like VB.NET, only Free-as-in-Speech.

    It doesn't sound like much, but for porting a lot of business logic to Linux, this is a potentially huge development.

    Another thing that's needed to get this project up to par with MS .NET is an IDE. Fortunately, the SharpDevelop [] folks are working on that...

    So far this project has been very impressive. Kudos to the Ximian folx.

    • by miguel ( 7116 ) on Tuesday December 10, 2002 @02:59AM (#4852082) Homepage
      An old version of the VB compiler is included in the release, but we did not have time to integrate the new VB compiler patches from Marco, but hopefully those will make it into the next release. There are screenshots of it in windows [] and with Gtk# [].

      SharpDevelop does require Windows.Forms, if you are interested in getting this superb development environment running on Linux with Mono (it includes Intellisense), you could help with the Windows.Forms porting effort []

  • by Anonymous Coward on Tuesday December 10, 2002 @03:02AM (#4852104)
    what good is ASP or ASP.NET if we already have PHP you might ask. Well, firstly, ASP is a Microsoft product. If you don't know, Microsoft is a reputable software company that has been in business since 1975. PHP is just some silly freeware ASP clone hosted by a buch of computer geeks and hackers on some obscure website. Clearly a product from a major player in the software industry will be a better product.
    • Re:ASP.NET or PHP (Score:5, Interesting)

      by miguel ( 7116 ) on Tuesday December 10, 2002 @03:14AM (#4852159) Homepage
      Well, having ASP.NET is very convenient to move applications and components from Windows and deploy them on Linux or Unix systems. So I think that this is a plus on its own.

      In terms of choices, I have to admit that I personally am more of an old school strongly-typed kind of person, and I like programming more with a language that I understand like C#. There is nothing wrong with PHP or Perl, but I feel a bit insecure with them. Like when you have to order water in a restaurant, and you do not want to look cheap, so you end up asking for `bottled water' even when you are trying to not spend a lot of money [1].

      Mono and .NET offer a very interesting crossroads: the possibility of sharing components and existing classes independently of the language that was used to create it.

      I strongly believe that scripting languages are great for quickly building web solutions, and I would love to see more work between the PHP (and other scripting communities) and Mono. We are certainly interested in helping out.

      For instance, the Mono runtime is easily embeddable [], it could be used in existing systems with ease: for example, allow any language but use the PHP API to write web pages is one option (check the link for a few more samples and the tutorials), or hosting any programming language on Apache (as its done with the Apache/Mono module mod_haydn [].


      [1] Although as you grow older, you become more cynical, and you just tell the waiter `Get me a glass of the cheapest form of water you have'.
      • I've always heard you weren't supposed to drink the water in Mexico. Maybe the bottled water isn't such a bad idea.


      • the possibility of sharing components and existing classes independently of the language that was used to create it.

        Can that be any language, or only special languages like VB and C#? If this is available for any language, then why invent a new language like C#?
        • Re:ASP.NET or PHP (Score:5, Informative)

          by miguel ( 7116 ) on Tuesday December 10, 2002 @03:40AM (#4852268) Homepage
          The "contract" for language interoperability is called the Common Language Specification [] (CLS) and furthermore, languages are divided in CLS producers, consumers and consumer/producers.

          You can think of the "CLS" as a richer contract than say the CORBA IDL or the COM IDL: they define APIs. Now on top there is a virtual machine that allows you to run either native code or "CIL" code that executes on the common runtime [].

          There are plenty of CIL compilers (C, C++, C#, JavaScript, Fortran, Cobol, Eiffel, Ada, VB, Haskell) that can produce/consume CLS code.

          It is great if your language can produce and consume CLS classes, but its also good it it can consume them, because then a large body of code is available to you.

          • Haskell.. (Score:3, Insightful)

            Just so people know, there's been much concern that the CLS will take languages that are paradigmatically different from the C/C++/C# family of langauges (like Haskell, which is a functional language) and strip away the syntax that makes them powerful in their own way (closures, continuations) until they're basically C/C++/C#, differing in syntax only.

            At which point, the CLS would no longer be a good thing.
      • Re:ASP.NET or PHP (Score:3, Insightful)

        by Corrado ( 64013 )
        Well, having ASP.NET is very convenient to move applications and components from Windows and deploy them on Linux or Unix systems. So I think that this is a plus on its own.

        Do you honestly think that Microsoft will allow this? Sure, they say it's great now, but what about in a couple of years? What are they going to sell?

        Desktops? No, Windows is now just a dumb terminal front end to .Net servers. Might as well use Mozilla & Mono.

        Oh, ok then, they will sell servers. No, all the .Net stuff will run on Linux/Solaris/OS390/etc.

        So, Microsoft wont be selling desktops and they wont be selling servers. That makes sense. What is the angle here? What money making scheme am I missing? Are they holding back on some prime APIs or maybe all the .Net classes are under some patent.
  • Hidden message here (Score:3, Informative)

    by darkwiz ( 114416 ) on Tuesday December 10, 2002 @03:32AM (#4852239)
    Not to detract from Miguel and the Mono team here, but I can't help but think that there has to be a hidden message in the image he used for a screen shot... I can't quite put my finger on it...

    Oh well <whistles>
  • by pVoid ( 607584 ) on Tuesday December 10, 2002 @03:42AM (#4852275)
    Can someone please explain why .NET is so good?

    Microsoft isn't really good at explaining itself in a rational manner because Bill has his head up his ass, and will not let his technical team talk. Instead his marketing team is in charge of explaining to the world what they do. As a result, .NET to me is something as low-level and small as a binary format specification (similar to COM objects), and as high-level and strategic as 'the end of non-distributed computing, and the emergance of <ooooh>Web Services</ooooh>'. Something that is so broad in breadth is not a clear definition in my books.

    Is there anyone out there that knows why .NET should supercede COM or CORBA? Why the functionality of Web Services isn't merely provided as an implementation in COM model?

    COM is a beautiful specification and model (so is CORBA - and the two are almost identical in fact)... they are compact enough to actually be usable in kernel mode (WMI providers in Windows are COM interfaces). So what is our eternal ass rash that makes us want to get the better suped up version of the same old shit?

    I don't know about other programmers, and how they feel of all of this, but a new standard evolving every 5 years is way to much for me. And as such, I have yet to be convinced I should start learning anything in .NET. What have you, comrades, to say about this? Have you started using .NET, and have seen fundamental differences in principle that make obsolescence for COM a MUST?

    On a side note, kudos to Mono for doing this work.

    • by miguel ( 7116 ) on Tuesday December 10, 2002 @03:55AM (#4852327) Homepage
      I am going to try.

      The .NET Framework is actually a new platform for software development, and incorporates many ideas that have been floating around before.

      The .NET Framework includes basically three components: programming languages, a common language runtime and a set of class libraries for acomplishing various kinds of tasks.

      The framework was designed so multiple programming languages could share the same set of class libraries with minimal effort, and also to allow a large set of programming languages to work together rather than having each one create its own "micro platform".

      Now, the .NET Framework offers a couple of ways of doing distributed computing with RPC calls: one is called the Remoting framework and the other one is called Web Services (its not exactly like this, but for now this will work).

      Remoting is the closest thing to a CORBA replacement, but its not a great replacement. I personally like CORBA more for plenty of reasons that I hope one day I will write down.

      Web Services is the "in" thing to do today, so the .NET Framework has some tools as well for making it easy for developers to write client and server applications using the web services protocols.

      Another things that .NET does is it simplifies the development of COM components and the use of COM components (there is plenty of literature on this subject on

      Most COM developers I have talked to claim that .NET makes them more productive. You wont loose a lot by trying it out, you can always go back to your current tool set if you do not like .NET.

      • common language runtime and a set of class libraries for acomplishing various kinds of tasks

        So if I understand you correctly, .NET is kind of like the enhancement of what automation was set out to be: a common way for any COM object abiding to automation rules and specifications to be able to use the environment (such as data, variables etc) of the application without doing 'marshalling conversions' when switching between languages? (for example: using variants and safe arrays to access data both in C++ and VB).

        I was aware of that, but still am not too clear on the full extent of this commonality.

        See, I understand the noble intent, but these are my gripes:

        Web Services could simply have been implemented as another 'standard interface' such as IMarshall... IWebService (or whatever...)

        Automation could have easily been 'enlarged', or extended so that all said languages (SQL, VB, C#, unmanaged C++ - via libraries) could interoperate. It's not like .NET is backward compatible... all the implementations of the languages will have to be changed anyhow...

        .NET, so far, is only more productive (IMHO), because of how good Moft's IDE is. And this has always been the case - Moft knows this very well, and has very well capitalized on the matter: the better your IDE and code generation suites are suited for RAD, the more market penetration you will get (because more programmers are programming for your platform)... Thus, ever since VC4, the capital focus has been on getting programmers to compile applications as fast as possible (hence all the wizards etc).

        I see your good intent, Miguel, but I still don't think it's a good enough reason for me. (just because, for example: COM is so elegant that it can actually be used in a fully interuptible-fully pre-emptible environment which is the NT kernel). More cruft, means more breaking points... means more IIS style security breaches that span several modules of runtime support.

        • by Otis_INF ( 130595 ) on Tuesday December 10, 2002 @05:22AM (#4852625) Homepage
          Let me start by saying that programming COM objects is the most retarted way of programming functionality. True, using VB or Delphi, it is easy, but using f.e. C++, it's not. Read Don Box' book Essential COM to see what I mean.

          COM as a functionality is great, but it should have been more transparent for the developer, like VB did this: you just program classes and hey, check it out, they're COM objects now!. Using Visual Studio, creating COM objects was (at least using ATL) a bit painless, but don't try it using f.e. UltraEdit32 and no helper library.

          So if I understand you correctly, .NET is kind of like the enhancement of what automation was set out to be: a common way for any COM object abiding to automation rules and specifications to be able to use the environment (such as data, variables etc) of the application without doing 'marshalling conversions' when switching between languages? (for example: using variants and safe arrays to access data both in C++ and VB).

          No. .NET is the replacement for the VB runtime for VB programmers, the C(++) Runtime / STL / Win32 lib for C/C++ programmers etc. It's the general target platform for _ALL_ CLS compliant languages (C#, VB.NET, J#, etc. C++ is partly CLS compliant, if you want to use templates or multiple inheritance, you can't).

          The multi-language part is not a result of 'making it a better marshaller' or better 'automation platform', but simply a result because now all languages have the same API, the same functionality on board: it doesn't matter which language you pick, you can target the same API and use the same cool functions with ease in VB.NET as you can in C++.NET.

          As a result of this, the code you compile will run in a VM. This VM, the CLR, is the heart of .NET. The objects you create, run inside application domains, which is totally different than COM objects do, in relation to the SCM.

          Webservices is a term for a piece of 'logic' as I call it. Functionality. It's not 1:1 projectable on a piece of code, like 'that class can serve as the base class for all webservices'. This is due to the fact that a webservice, when you use SOAP f.e., depends on a lot of tiny building blocks to do whatever it should do. That's why it couldn't be another Interface. (I also doubt what that would have brought to the plate, you can create webservices using the new ATL extensions and using plain C++, thus not .NET, but its harder). Webservices is not a 'part' of .NET, you can build webservices WITH .NET. That's a different thing!

          About the productivity: Now people can use a language that suits their needs and preferences (f.e. I prefer C# over VB.NET, while I've developer a lot of COM objects for n-tier systems in VB) and use a much richer API than they ever could. It doesn't depend on MS' tools. Sure the new is great, but the rich .NET api is the key of its success. Add to that the wonderful ASP.NET functionality (which is really years ahead of anything else) and the very good documentation of the API and you're set.

          Also I don't see your kick in the balls towards IIS style security. To me this sounds like you really do not understand 1) the power of the strong typing inside .NET and the amazing security featureset available to a developer and 2) that COM IS one of the causes of security leaks and DDos attack possibilities, simply because people forgot to use smartpointers and kept memory nonfreed. This is over now.
          • First off:

            To me this sounds like you really do not understand

            Be good. Instead of trying to win the argument by accusation, try to see what I'm talking about.

            C++ is a strongly typed language. Yet it can be horribly prone to errors.

            COM is *not* a source of security leaks. That's like saying DLLs and EXEs are a source of security leaks. Destroy them.

            As I said earlier in anther post, all of what you mentionned above could have been achieved by simply enhancing/creating the two languages you mentionned: C#, VB. VB up till now didn't support proper object orientation. And it's compiler was pretty much crap (internals weren't thread safe etc.etc.etc)...

            All the new Good Things (tm) you are talking about here have already been done with Java. Why not just use Java then?

            And this comes back to a secular war between Java and C++ people. About how some people defend their right to use C++, which has templates, and some other people don't know what templates are and say C++ is a hack job.

            Whatever your choice, you have to respect the others too... and saying "well, sorry, STL is gone, and templates supports are gone... because now you have an object model for your entire API" isn't gonna cut it for me.

            What I mean by the kick in the balls towards IIS style security: it's quite a simple engineering concept really... the more complex your system, the easier for there to be bugs, flaws. It's that simple.

            COM, is in it's essence, as broad and neutral a specification as PE, or ELF. It basically defines binary entry points in a binary file, defines method calling conventions, and memory allocation conventions through those method calls.

            Last of all, if you've used ATL, and do not realize what a beautifuly useful library it is, I don't think we should be talking here... Have a good time using your .NET objects that you created via UltraEdit.

          • > Let me start by saying that programming COM objects is the most retarted way of programming functionality. True, using VB or Delphi, it is easy, but using f.e. C++, it's not. Read Don Box' book Essential COM to see what I mean.

            No, it's not.
            First off, COM is a great way to combine parts of programs together. And if you want to have COM in C++, yes, you've to do quite a bit yourself, because in C++ you *don't* have things done under-the-scenes for you.

            COM itself is quite simple, IUknown and nothing much beside it. The interfaces are complex, because you do quite a lot with them, and with combinations of them.
            That is why you can have a lot of stuff automated for you by librarys, ATL is a good example, but certainly not the only one.
      • (Score:5, Informative) by miguel (7116)
        (Score:5, Informative) by miguel (7116)
        (Score:5, Informative) by miguel (7116)
        (Score:5, Informative) by miguel (7116)
        (Score:5, Informative) by miguel (7116)

        Okay, I don't know who you think you are, Mr. miguel (7116) (if that's even your real name), but if you think you can Karma Whore your way to success by posting a bunch of information from other sites [] and posting a mess of links, you have another think coming!

        You big jerk. ;)

    • Re:.NET vs COM/COM+ (Score:5, Informative)

      by Glorat ( 414139 ) on Tuesday December 10, 2002 @09:36AM (#4853642)
      A very succinct explanation I got while on a .NET training course was that .NET reversed something that Microsoft got wrong:

      COM: A very lightweight wrapper for intra-machine communication. Low overhead and fast. Forces programmer to handle all other issues like memory management, implementing interfaces etc. etc.

      COM+: A heavyweight framework for inter-machine (remote) execution. Tries to do all things and as such suffers from being ghastly to set up and use

      In short
      COM: Light for local machine execution
      COM+: Heavy for remote execution

      Microsoft decided they got this completely wrong and have reversed it

      dotNET local machine: Uses a CLR and common type system. This handles all memory management etc. etc. inside a virtual machine making things easy for the coder (with overhead of course)

      dotNET remoting: Has become very lightweight. You just send XML soap messages over TCP. That's light and that's also what web services are based on. Can you imagine even considering web servicse with COM+ ?

      So that's what they've changed in terms of COM/COM+. Having used it, I'm glad I never have to touch COM+ again and I'm glad that Microsoft have realised that a java style CLR/VM works well for general programming
    • I'll try to hit the high points I've found without mentioning any of the stuff you're likely to have heard of in the marketing materials.

      There are two fundamental differences between .Net and COM that I think are pretty compelling.

      1.) COM is interface oriented and .Net is object oriented. True, you can do COM with OO languages like C+, but at the COM layer you're still fairly restricted in terms of what you can easily pass between processes. IDL is not very friendly when it comes to complex data types and creating interfaces that require the marshalling of them has some nasty side effects in terms of dependencies between components, not to mention the need for custom marshallers.

      As a result, most distributed app's based on COM usually work by passing simple data between tiers instead of passing objects. Each tier winds up implementing code that consumes that data into a redundant object model.

      In contrast, .Net objects are fairly easy to manipulate between tiers. There are three basic serialization technologies in the framework, (XML, Binary, and SOAP) as well as support for a variety of protocols (remoting channels include SOAP, HTTP, and TCP) and rolling your own is not that hard to do.

      Admittedly, the client and server bits still need to understand the type definitions, but passing an object around that encapsulates data and enforces business rules is very straightforward. With .Net you can be OO and avoid the expense of chatty interfaces that cross physical and process boundaries.

      For example, I just did an app that sends and receives objects that are serialized and deserialized to and from XML between a Windows Service and a mainframe using MQ-Series.

      2.) .Net assemblies, by default, are local to the project path instead of being global to the machine and do not depend on the registry. In terms of time savers, this one is huge (no more DLL hell!) and it makes both versioning and deployment a lot easier.

      Because of this, you can run two versions of the same application side-by-side, you can deploy an application with XCopy or from a web server (with the right security policy you can place a WinForm app on a web server and .Net will download it to a cache and execute it just like it was insatlled on the machine), and because .Net supports code signing, you can (if you want) ensure that referencing bits will only load specific versions (and protect yourself from Trojans).

      Finally, these are complimentary technologies. If the application is truly distributed between diverse environments, there is no reason not to mix-and-match RPC models. However at the boundaries, .Net really shines. And if it is a 100% .Net implementation, you're left wondering how you ever put up with the headaches inherent in COM in the first place!
  • by kir ( 583 )
    ...what the heck is .Net? Now, before you drill me as a moron or a troll, hear me out.

    I've some vague understanding about what .Net is and what it is supposed to provide (XML web services... OK.), but can anyone point me to a good primer on the matter?

    I've never even tried to keep up with .Net (WTF kind of name is that anyway?). I've got enough to keep me busy without having to worry "the next big thing".
    • You could start here:
      Oreilly Network ONDotNet []
    • what the heck is .Net?

      Basically, the .NET framework evolved from the COM+ framework earlier and is Microsoft's answer to middleware. .NET's biggest competitor is the J2EE specification, with implementations from BEA (WebLogic), IBM (WebSphere) and Oracle (iAS) the biggest names in the business. Apart from J2EE, there's always custom middleware, forex building your own CORBA components and custom data access code. More control over the stuff, but more bug prone as well.

      Technologies included in the .NET framework:
      • CRI(?) The Common Runtime layer. The thing which runs the compiled code, sort of comparable to a Java runtime environment.
      • Several languages: C#, VB.NET,, J#, maybe some other language I forgot. They all run on the Common Runtime layer and therefore 100% interoperable. A C# module can call a VB.NET module.
      • ASP.NET: ASP as it should have been done. Brings it up to par with JSP.
      • Support for XML Web services. Calling modules over a http call using XML/SOAP.
      • ...

      Basically, anyone who imlements a CRI will be able to run .NET applications, so theoretically it's not a Microsoft only platform. I seem to remember that Microsoft also released a beta for BSD just to make that point. But so far, as expected, there's no real serious alternative to the .NET platform released by Microsoft for Windows.

      • For a Java oriented serverside programming site: The Serverside []
      • Several O'Reilly titles: .NET framework (more general), Programming C#, Programming ASP.NET (last two specific for the languages)
      • Wrox has a good set of .NET books that are worth looking into

      Caveat when buying books: see that they cover the latest release and not forex the beta release!
  • by sanermind ( 512885 ) on Tuesday December 10, 2002 @03:55AM (#4852322)
    It almost seems like blasphemy [] to be able to compile and run Visual Basic in a linux environment. Yikes! What is this interoperable world coming to? What next, a paperclip for emacs? ;)

  • by PsyQ ( 87838 ) on Tuesday December 10, 2002 @04:46AM (#4852493) Homepage
    Is the performance still acceptable and can compatibility be guaranteed? Chillisoft ASP is great if you're a commercial ISP or otherwise make money from hosting ASP stuff, and therefore can afford the price. But for the little educational student webserver, it's out of the question.

    Can this compete? Or do the users have to learn a whole new brand of ".NET ASP" to do anything useful with it? I never knew anyone who uses ASP, so I never looked -- are there other free ASP-on-Linux solutions out there?
    • ASP.NET is fundamentally a pretty different (and much more advanced) technology than ASP.
    • It is not an alternative to Chillisoft ASP, it is more of a complement.

      Chillisoft ASP implements the old ASP system for Unix systems. ASP.NET is radically different from ASP, pretty much the only thing they share is the name and the fact that they are web-related technologies.

      ASP.NET was originally a project inside Microsoft by a few guys that wanted to do ASP-like systems "right", and they called this system XSP. Later marketing came and figured `The right name for this technology is to reuse the old name, and stick a .NET at the end'. So they did.

      So if you have systems that you want to move to Unix/Linux that currently use ASP, you will go for Chillisoft. If you have systems that you want to move to Linux/Unix that use ASP.NET you go with Mono.

      ASP developers do have to learn this new technology, as it has almost no relationship with the old platform.

  • by johnburton ( 21870 ) <> on Tuesday December 10, 2002 @04:54AM (#4852522) Homepage
    This may be a stupid question but does mono work on windows? Everything seems to imply it will but then the downloads section all seem to be for linux. I'd be interested in having a play with it on windows as it's the only environment available to me most of the time.
    • The binaries run fine in windows xp with .net installed.
  • mono on windows95 (Score:4, Interesting)

    by mcbevin ( 450303 ) on Tuesday December 10, 2002 @05:00AM (#4852547) Homepage
    one useful feature mono will hopefully provide is the ability to run .net programs on older _windows_ systems.

    thats right :) - microsoft doesn't support .net on windows 95 (presumably as part of their overall strategy to force upgrades by making their old os versions obselete).

    having written a windows forms application (the decision to use windows forms based on the fact that it really is one thousand times nicer than win32/mfc to create gui applications with), i was a bit shocked to find out that my application won't run under windows 95 at all, and that for other old microsoft OSes a TWENTY megabyte download is required to support it! (a bit of a jump from the one or two megabytes for the visual basic dlls).

    and one further note - about 'pure' .net applications (ones that don't call the win32 api and are thus potentially more portable) - the inability to do any multimedia stuff (even a simple beep) without resorting to win32 calls, makes it pretty much impossible for any reasonably large application :).
    • Re:mono on windows95 (Score:2, Informative)

      by TummyX ( 84871 )

      and one further note - about 'pure' .net applications (ones that don't call the win32 api and are thus potentially more portable) - the inability to do any multimedia stuff (even a simple beep) without resorting to win32 calls, makes it pretty much impossible for any reasonably large application :).

      Not necessarily true. You can make 'purer' .NET applications by doing P/Invoke calls to cross platform C apis instead of Win32 APIs.

      For example, if you use SDL instead of DirectSound your .NET application will run on Unix and Windows. .NET makes it easy to access traditionall DLLs with P/Invoke but that doesn't mean they have to be Win32 DLLs :).
  • STD (Score:2, Funny)

    by stud9920 ( 236753 )
    Does mono ship with a VD-compiler ?
  • WAKE UP (Score:4, Insightful)

    by e40 ( 448424 ) on Tuesday December 10, 2002 @11:21AM (#4854542) Journal
    From a technical perspective, .NET might be a very nice platform. I'm certaining hearing that it is. The speed with which the Mono team formed and started executing was impressive.

    People, you need to wake up. Stop being technophiles and think. This is Microsoft we are talking about here. They do NOTHING for the benefit of their customers. They do EVERYTHING to gain market share and ensure the domination of their operating system.

    MS is playing "nice" now by not serving legal injunctions based on their patents. Will they continue?

    Let's say some of the people that reply to this post say "The patents are irrelevant blah blah blah blah". OK, fine. Let's say they are. That doesn't even matter, here's why:

    MS defines .NET. Mono copies that design. If Microsoft's patents were not enough to stop people using .NET apps on non-MS platforms, all MS has to do is CHANGE THE DESIGN.

    Remember when OS/2 had win32s compatibility? Remember Microsoft's response? IBM took the win32s distribution from MS and binary mapped it into a valid set of OS/2 libraries and programs. Within a very short period of time, MS released a NEW VERSION OF WIN32S TO BREAK IBM'S USE. Analysis at the time showed that the changes, which were few, were gratuitous and the only conclusion was as I've stated it. I did some googling and this [] is a good summary.

    If Mono is too successful, this will happen again. "Too successful" means that .NET apps will be TRULY portable, something MS DOES NOT WANT because it makes their platform inconsequential. In fact, if they did not defend their platform, this would be the death of MS.

    Let me put it another way:

    Microsoft is enabling, for the first time in their history, users to write portable programs and that portability could kill or severely damage Microsoft. Microsoft knows that they will be able to prevent this, if need be, and they will only show that card if they need to. After all, no need to give the conspiracy theorists ammo, right?

Seen on a button at an SF Convention: Veteran of the Bermuda Triangle Expeditionary Force. 1990-1951.