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). "
bleh. (Score:2, Funny)
Re:bleh. (Score:2, Funny)
Re:bleh. (Score:2)
Re:bleh. (Score:4, Interesting)
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.
/home/linuxuser$ mint myapp.exe (Score:5, Insightful)
Re:/home/linuxuser$ mint myapp.exe (Score:5, Informative)
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: http://www.go-mono.com/winforms.html (for the Windows.Forms plans and mailing lists)
Miguel
Re:/home/linuxuser$ mint myapp.exe (Score:3, Interesting)
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.
Re:/home/linuxuser$ mint myapp.exe (Score:5, Informative)
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 bugzilla.ximian.com, they might be worth following up.
Miguel.
Re:/home/linuxuser$ mint myapp.exe (Score:2, Insightful)
Re:/home/linuxuser$ mint myapp.exe (Score:2, Interesting)
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
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
Re:/home/linuxuser$ mint myapp.exe (Score:3)
Let it ride dude, it sure beats "grits" or cluster imagining.
Re:/home/linuxuser$ mint myapp.exe (Score:4, Interesting)
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....
VM questions for Miguel (Score:3, Interesting)
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.
Re:/home/linuxuser$ mint myapp.exe (Score:5, Informative)
(I heard today on the irc channel for mono (irc.gnome.org, channel #mono) that the upcoming 0.6 release of Gtk# will distribute all the files you need for running on Windows as well).
Re:/home/linuxuser$ mint myapp.exe (Score:4, Informative)
That's nice (Score:2, Interesting)
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)
All signs point to yes.
Re:That's nice (Score:5, Insightful)
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.
Re:That's nice (Score:2, Flamebait)
J2EE is a mess. Whether .NET matches up with it or not doesn't matter.
Re:That's nice (Score:4, Interesting)
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 [dreambean.com] 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.
Does Mono build on MacOS X? (Score:2, Interesting)
Has anyone tried building Mono on MacOS?
Re:Does Mono build on MacOS X? (Score:5, Informative)
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.
Re:Does Mono build on MacOS X? (Score:3, Interesting)
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 kylix.net apps on nutty old macs!)
Re:Does Mono build on MacOS X? (Score:3)
Now, just like the current JIT, we do require copyright assignments to the runtime code base, and we do in fact relicense the runtime to those who are interested in it, but the LGPL version will always be available.
Miguel
Yay Mono team (Score:2, Insightful)
Re:Yay Mono team (Score:5, Interesting)
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)
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" ?
Re:Yay Mono team (Score:3)
My original question asked what made it better than GTK+'s forms. We've already established they have a new forms implementation that's supposedly good.
Yes VB6 comes to mind immeditely
That's a classic example of what I was on about. VB6 was around at the time I started having a look at GTK+. VB6 has all the flaws that my original post was talking about. If I had rememberd VB6, I would have mentioned it.
Your original message compares the low-level Win32 APIs with GTK+
Blah. My message compared GTK+ to MFC, both were the current standard on their respective platforms at the time I used them.
Bravo! (Score:2, Insightful)
Re:Bravo! (Score:2, Insightful)
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
Tell me, where is the innovation? (Score:4, Insightful)
It CAN be about innovation by implementing generics into the Mono runtime before MS does this (MS will release the updated 2.0
Dangerous Because of Microsoft Patent Claims Trap (Score:5, Insightful)
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 [apache.org] . Sun has also fully pened up the Java development standards process under the new Java Community Process (JCP) [jcp.org]. Even to the point of granting full open source re-implentations of J2EE such as JBoss [theregister.co.uk]...
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.
Re: Dangerous Because of Microsoft Patent Claims T (Score:2)
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.
Re: Dangerous Because of Microsoft Patent Claims T (Score:3, Informative)
No. You're thinking of trademarks. If you let a trademark get diluted in the marketplace, your claim to that trademark grows weaker, or even goes away entirely. Patents don't work like that.
Re: Dangerous Because of Microsoft Patent Claims T (Score:2)
Tell that to Unisys - Gif patents (Score:4, Interesting)
Re: Dangerous Because of Microsoft Patent Claims T (Score:2)
Re: Dangerous Because of Microsoft Patent Claims T (Score:2)
same problem exists with Sun (Score:4, Troll)
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.
Re:same problem exists with Sun (Score:4, Insightful)
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.
Re:same problem exists with Sun (Score:5, Informative)
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.
Curious - what is your problem with JCP? (Score:3, Interesting)
Microsoft patents are irrelevant (Score:5, Informative)
Sun's patents, if anything, look much more worrisome. For example, patent 6,477,702 [uspto.gov] 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.
EVERYONE TAKE HEED OF THIS!!! (Score:5, Insightful)
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.
Re:Worth the risk (Score:3, Informative)
C# will be and ISO standard. To be published shortly:
ISO/IEC 23270 (C#)
ISO/IEC 23271 (CLI)
ISO/IEC 23272 (CLI TR)
"In late December, 2001, ECMA submitted the standards and TR to ISO/IEC JTC 1 via the latter's Fast-Track process. The subsequent 6-month evaluation and comment period resulted in two NO votes (Japan and UK) on the draft standards, and one NO vote (Japan) on the draft TR. All comments resulting from this review were considered at a ballot resolution meeting held in October, 2002. The two NO votes on the standards were resolved, making acceptance unanimous. However, Japan did not change its NO vote on the draft TR (Japan would like to see a formatted/readable rendering of the CLI class library as part of the standard, not as a TR; this will be considered for a future edition).
The ISO/IEC standards and TR will be published in December, 2002, and will be known formally as ISO/IEC 23270 (C#), ISO/IEC 23271 (CLI) and ISO/IEC 23272 (CLI TR). Equivalent specifications will be adopted as 2nd edition standards and TR by ECMA at its December, 2002, General Assembly."
The full story is here [microsoft.com].
What they didn't announce... (Score:5, Informative)
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 [icsharpcode.net]
folks are working on that...
So far this project has been very impressive. Kudos to the Ximian folx.
Re:What they didn't announce... (Score:5, Informative)
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 [go-mono.com]
Miguel.
ASP.NET or PHP (Score:3, Funny)
Re:ASP.NET or PHP (Score:5, Interesting)
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 [go-mono.com], 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 [sourceforge.net].
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'.
Re:ASP.NET or PHP (Score:2)
Regards
Re:ASP.NET or PHP (Score:2)
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)
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 [www.ecma.ch].
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.
Haskell.. (Score:3, Insightful)
At which point, the CLS would no longer be a good thing.
Re:ASP.NET or PHP (Score:3, Insightful)
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
Oh, ok then, they will sell servers. No, all the
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
Hidden message here (Score:3, Informative)
Oh well <whistles>
COM, CORBA, J2EE, .NET... (Score:4, Insightful)
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.
Re:COM, CORBA, J2EE, .NET... (Score:5, Informative)
The
The
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
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
Another things that
Most COM developers I have talked to claim that
Miguel
Re:COM, CORBA, J2EE, .NET... (Score:2)
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...
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.
No, read on to know why: (Score:5, Informative)
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
Re:No, read on to know why: (Score:3, Insightful)
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.
Re:No, read on to know why: (Score:3, Insightful)
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.
Re:COM, CORBA, J2EE, .NET... (Score:3, Funny)
(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 [go-mono.org] and posting a mess of links, you have another think coming!
You big jerk.
PDHoss
Re:.NET vs COM/COM+ (Score:5, Informative)
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
Re:COM, CORBA, J2EE, .NET... (Score:3, Insightful)
There are two fundamental differences between
1.) COM is interface oriented and
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,
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
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.)
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
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,
Sort of off-topic, but... (Score:2, Redundant)
I've some vague understanding about what
I've never even tried to keep up with
Re:Sort of off-topic, but... (Score:2, Informative)
Oreilly Network ONDotNet [ondotnet.com]
Re:Sort of off-topic, but... (Score:3, Interesting)
Basically, the
Technologies included in the
Basically, anyone who imlements a CRI will be able to run
Primers:
Caveat when buying books: see that they cover the latest release and not forex the beta release!
Temperature drops in hell (Score:3, Funny)
Re:Temperature drops in hell (Score:3, Funny)
Vigor [sf.net]
Paperclip ALREADY in Emacs... (Score:3, Funny)
Of course in Emacs he is called Pinhead and is much more helpful.
A valid alternative to Chillisoft ASP? (Score:3, Interesting)
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?
Re:A valid alternative to Chillisoft ASP? (Score:3, Informative)
Re:A valid alternative to Chillisoft ASP? (Score:3, Informative)
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
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.
Miguel.
Does it build on windows? (Score:3, Interesting)
Re:Does it build on windows? (Score:2)
Re:Does it build on windows? (Score:3, Informative)
mono on windows95 (Score:4, Interesting)
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'
Re:mono on windows95 (Score:2, Informative)
and one further note - about 'pure'
Not necessarily true. You can make 'purer'
For example, if you use SDL instead of DirectSound your
STD (Score:2, Funny)
WAKE UP (Score:4, Insightful)
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 [google.com] 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?
Re:No DB2? (Score:5, Interesting)
It is easy to know when the System.Data hackers are working, your inbox gets hammered with patches from the mono-patches [ximian.com] 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).
Re:?? Love it or Hate it ?? (Score:3, Funny)
Love it (Score:3, Insightful)
On the other hand, if you are less of an ideologue and more practical about technology, Mono makes it "safe" to use MS technologies when they are the best choice, because you don't have to make everything MS. You can order a la carte.
Re:That's nothing compared to Parrot (Score:2)
Why are you so insecure that the very existence of another project gets you so worked up? Kinda sad, really, that you feel the need to spoil what should be a good brag moment for Miguel and company.
This is Miguel's announcement. Put your bile away and don't spoil it.
Re:What, no COM support? (Score:3, Interesting)
What's the purpose of such a thing?
Are you also trying to peel off CORBA reliance?
Please explain your point of view, because I just can't understand why people are running away from COM as if it were the plague... and into this new swamp that is .NET.
Re:What, no COM support? (Score:2, Informative)
Please explain your point of view, because I just can't understand why people are running away from COM as if it were the plague
Um. Because
COM relies too much on windows APIs, it's not cross platform, it relies too much on the system registry and it only works on windows.
Re:What, no COM support? (Score:4, Insightful)
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.
Re:What, no COM support? (Score:3, Interesting)
How do you tihnk CoCreateInstance constructs an object from a classid?
How do you think COM knows which IID relates to which interface?
Yes. The registry.
You have to register all com interfaces and objects in the registry.
COM simply wouldn't work without some kind of registry or repository.
Re:What, no COM support? (Score:3, Informative)
Aside from that, CoCreateInstance might in a windows implementation look up the registry... but it might in a linux implementation look up a flat file, and on a BSD imp look in a sql db... it wouldn't change the behaviour of CoCreateInstance... And so, CoCreateInstance as a definition is not tied to any specific platform.
COM works on Mac OS :P (Score:2)
I agree that there is no need for porting COM to Linux. COM was a great technology to provide functionality to a wide spread of languages. That is now taken care of by
Re:What, no COM support? (Score:3, Insightful)
No. You create references to assembly filesnames in your own assembly and with that also a version of the assembly so you can install multiple assemblies with the same filename. I can call my assembly FOO and the assembly file bar.dll. The compiler creates a reference to 'bar.dll' with a certain version. When I start the program with that reference, the CLR will look in the current directory for bar.dll to load the assembly objects I try to instantiate. If bar.dll is missing it will consult the GAC (Global Assembly Cache). If bar.dll is not found there, it's not loaded.
Mono is designed to be cross platform.
No. _.NET_ is designed to be cross platform, since the platform a class talks to, uses and consumes is
Supporting COM in
Re:What, no COM support? (Score:2)
How do you think COM knows which IID relates to which interface
COM doesn't know that. IUnknown::QueryInterface (implemented by your object) knows that.
Re:What, no COM support? (Score:2)
COM is language independant. It's a binary format with a small number of runtime environment support routines... it is not platform dependant. Incidentally, COM objects interacting with only other COM objects are also platform independant.
Platform independance is not a reason to supercede COM.
Re:Amazing! (Score:3, Insightful)
I don't think this project should be considered a counter attack. It should be considered an advancement in open source and nothing more. Just my opinion
IN SOVIET RUSSIA.... (Score:3, Funny)
Re:IN SOVIET RUSSIA.... (Score:3, Funny)
YOU piss off the "in soviet russia" jokes!
Re:Someone tell me: What's the big deal? (Score:4, Insightful)
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.
Re:Someone tell me: What's the big deal? (Score:3, Interesting)
As for most of your other complaints, they all involve cost. So here we have this Mono implementation. On top of that the
"Please someone tell me what's the big deal of all this crap?"
If all you know about is Linux news you saw on
Re:This is great and all but I have 1 BIG question (Score:3, Informative)
The wait will be worth it. I can not talk about release dates. I can tell you that a number of previews has been sent to alpha testers for evaluation, and we will have to incorporate their feedback before we are ready to release the new version.
Now the right person to talk about these things is Nat Friedman who is in charge of the desktop work. He has quite a few new tricks for the new release, but I wont spoil his debuting new desktop here
miguel.
Re:What a tremendous waste of time (Score:3, Interesting)