Slashdot Mirror
Mono Ships ASP.NET server
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). "
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.
.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.
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...
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.
Just like Microsoft is outspending the Apache Foundation?
Sun/IBM/BEA/Oracle/Apache.. Microsoft may well pull it off, but it's hardly a foregone conclusion.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
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.
Finding God in a Dog
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.
The volume of database providers in this release is the work of very few but very active hackers: Brian, Dan, Rodrigo, Tim and Ville. It is amazing the amount of code that these hackers pulled in the last two months.
It is easy to know when the System.Data hackers are working, your inbox gets hammered with patches from the mono-patches list.
You can help us support DB2, but you will have to get your hands dirty and start coding like the crazy hackers that brought all these providers (and Reggie has agreed to contribute his optimized provider as well).
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.
.NET offer a very interesting crossroads: the possibility of sharing components and existing classes independently of the language that was used to create it.
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
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.
Miguel.
[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'.
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.
Unisys were well aware of the widespread use of LZW GIF image compression in many vendors software, so it's better to use PNG.
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.
Miguel.
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.
Hmmm... Have you used COM before?
STDAPI CoCreateInstance( REFCLSID rclsid, //Class identifier (CLSID) of the object
LPUNKNOWN pUnkOuter, //Pointer to controlling IUnknown
DWORD dwClsContext, //Context for running executable code
REFIID riid, //Reference to the identifier of the interface
LPVOID * ppv //Address of output variable that receives
);
Can you tell me where you see the registry in there? Even malloc is shielded behind an IMalloc interface for crying out loud. The implementation of the runtime happens to use the registry, but that is COMPLETELY hidden to the actual spec of what COM is.
There are so many things wrong with that that it's hard to know where to begin:
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.
one useful feature mono will hopefully provide is the ability to run .net programs on older _windows_ systems.
:) - 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).
.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 :).
thats right
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'
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.
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.
.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). .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#, JSCript.net etc. C++ is partly CLS compliant, if you want to use templates or multiple inheritance, you can't).
.NET. The objects you create, run inside application domains, which is totally different than COM objects do, in relation to the SCM.
.NET, but its harder). Webservices is not a 'part' of .NET, you can build webservices WITH .NET. That's a different thing!
.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.
.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.
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,
No.
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
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
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 VS.net is great, but the rich
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
Never underestimate the relief of true separation of Religion and State.
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.
.NET when Yukon (SQLServer 2003) comes out, late 2003, which will have generics support). However I don't see this happen soon.
It CAN be about innovation by implementing generics into the Mono runtime before MS does this (MS will release the updated 2.0
Never underestimate the relief of true separation of Religion and State.
This guy is 100% correct.
.NET/Mono, Microsoft turns around a sues them for royalties.
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
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.
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
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" ?
Follow me
Yes, People Should be doing new development in something else.
That said, there are a couple of reasons to support .NET on other platforms via mono::
.NET (hard to imagine with it being so new).
.NET anyway for business reasons or lack of knowledge about other options. That same codebase may not be ported to other platforms by the authors or others, so the only way to get it outside of windows is to move the entire environment out.
1. There is already some old code out there for
2. There are plenty of developers who will go ahead and develop in
Mono makes it possible (or will eventually make it ppssible) to take complete .NET applications and run them on something other than Windows. This will end the Windows Lock-in factor for a lot of one-platform applications.
A Lot of business decisions are based on the application software, not the OS platform. The software is chosen first, then the platform is brought in to support it. By making the platform choice wider, businesses can opt for something other than Windows to support their .NET applications.
The ultimate goal is to simply have all developers develop for something other than windows. But it's a long slow process to change that mindset and technical merit often has an alarmingly low priority in that process.
There is nothing so silly as other peoples traditions, and nothing so sacred as our own.
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.
.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.
.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.
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
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
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?
You're talking about the The Middleware Company's "shootout" between their "optimized" PetStore implementation and their .NET version.
Laying aside that Sun never put the PetStore demo forward as a benchmark, The Middleware Company did a lot to optimize the .NET version that they did not do for the Java version. The fact that Microsoft was paying for the comparison may have had something to do with this.
Read Rickard Öberg's analysis of the comparison to learn all of the ways in which the comparison was flawed. To name just one, The Middleware Company announced that it took fewer lines of code in the .NET version to do the same thing, but they left methods in their Java version that were never even called anywhere in the code.
In addition, the .NET version did aggressive caching in memory, in such a way that it would be impossible to scale the code across more than one server, while the J2EE version was implemented using BMP, which robs an application server of the ability to do any caching whatsoever.
It goes on and on and on. Read the analysis for yourself.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
For instance:
Again, I'm trying to look at reasons why I would prefer PHP to ASP.NET, and it seems like there are reasons that you are convinced are compelling, so I'd be interested in hearing them.