OSNews

"So apparently .NET does not create cross-platform applications by default and you have to invest extra effort to port them. "

No, but good developers do. Any app which is going to be cross platform requires a substantially larger investment up front if it is to run correctly...which brings me to:

"Many of the issues they discuss are pretty serious: using backslashes as path separators and case-insensitive filenames are common practice, platform invokes too"

Seasoned .Net devs know about Path.DirectorySeparatorChar (which provides an abstraction for the path separator character), and regardless of programming languages, string comparison (i.e. file names in this case) should always be done in a case-insensitive manner unless there is a specific reason not to do so. String.Equals has an overload that accepts a StringComparison enum to allow for case insensitive comparison, and most .Net devs make it a habit to almost always call string.ToLower().Trim() if they can't use the Equals method.

Platform invokes should be implemented as a separate library...there is no way of getting around them in some cases, but if they are pulled out of core code, then a suitable library can be written for other platforms utilizing their version of p/invoke (I don't know what Mono's is) and swapped out during deployment.

By no means are these serious issues as we're taught all of this fairly early on.

"And doesn't Java work everywhere already?"

There is a runtime available for almost all platforms, but a good bit of tweaking is usually needed for different platforms for non-trivial applications (meaning larger than java applets).

Edited 2007-06-04 06:44

"but a good bit of tweaking is usually needed for different platforms for non-trivial applications (meaning larger than java applets). "

What a FUD. care to explain those good bit of tweakings?

Path separators, hard coded paths and others can also break portability for Java and for any other programming environment.

Consider for example a program that hard codes the file with hosts as being "C:hosts" regardless of the language/runtime that you are using, the above will fail in non-Windows systems (And Windows systems with a non C: root).

And doesn't Java work everywhere already?

This statement/question simply invalidates your entire argument.

I have used PLENTY of java apps that only work properly on a single platform (usually Windows - surprise!).

Often this is either due to the use of JNI (Java Native Interface - read: platform-specific), or stupid code that only works on one platform (similar to assuming backslashes are OK in pathnames everywhere).

My impression is that Java "works everywhere" just as well as .NET code does at this point. Java has simply been in the game longer. This means there are many more platforms supported (officially even) and developers have been forced to learn the hard way how to write truly cross-platform Java code.

Winforms is essentially a platform-specific .NET API as it is - I mean even the name suggests this. I would not expect to write GTK+ software and have it work on a platform that has no GTK+ support - likewise with Winforms. It is amazing that Mono supports it as well as it does - and Microsoft never intended for Winforms to be cross-platform anyway I suspect.

I have used PLENTY of java apps that only work properly on a single platform (usually Windows - surprise!).

Often this is either due to the use of JNI (Java Native Interface - read: platform-specific), or stupid code that only works on one platform (similar to assuming backslashes are OK in pathnames everywhere).

Install wine and then install the Windows version of Java on wine. Run your application through that setup, and it works. It's worked for many years.

Now try the same with Mono and an application using platform invokes and it won't work. It won't work for many years.

Windows.Forms. Yay! Which has now been deprecated by Microsoft in favour of Avalon, and where no one is quite sure what the future of Windows.Forms is. Nice way to waste a lot of developer time and effort at Microsoft's behest ;-). I digress though.

Often this is either due to the use of JNI (Java Native Interface - read: platform-specific), or stupid code that only works on one platform (similar to assuming backslashes are OK in pathnames everywhere).

JNI can certainly be used in Java, but even worse is the effect of .Net's P/Invoke. You see, all .Net is is a great big object oriented wrapper around Win32 and existing COM components, and where there are things that aren't or can't be wrapped, or where performance is an issue, P/Invoke inevitably becomes an issue.

This is the sole reason why JNI gets used on Windows usually - because of hooks into pre-existing COM servers that will be around for some time. It's not Java that's the issue there.

You even have the option of running the JRE under Wine if this is an issue for you, whereas Mono just cannot do that and can give you no option at all for portability there. Don't expect Microsoft to help out with running under Wine any time soon on that front.

Windows.Forms. Yay! Which has now been deprecated by Microsoft in favour of Avalon, and where no one is quite sure what the future of Windows.Forms is. Nice way to waste a lot of developer time and effort at Microsoft's behest ;-). I digress though.


And also Win32-based and MFC development is on the same bucket, but the are still hundreds of thousands of applications using those APIs.

The same happens with Windows.Forms, what we offer is the chance for those applications to run on Linux because people do not switch to the latest toolkit as soon as it comes out.

Some people are able to switch API as soon as they are released, the "early adopters", and smaller projects can afford to do rewrite their code bases, but the majority of people do not rewrite their code overnight without a good reason, it is after all a waste of money.

You should know better, in fact, you probably do. But it would not serve your purpose of bashing Mono yet again and would defeat your point.


You even have the option of running the JRE under Wine if this is an issue for you, whereas Mono just cannot do that and can give you no option at all for portability there. Don't expect Microsoft to help out with running under Wine any time soon on that front.


Ah, making things up to prove a point.

What a sad thing.

Miguel

And also Win32-based and MFC development is on the same bucket, but the are still hundreds of thousands of applications using those APIs.

Yes, people have a ton of stuff written for Win32, and with COM that won't be rewritten? What does Mono actually offer them there over any other cross-platform technology?

The same happens with Windows.Forms, what we offer is the chance for those applications to run on Linux because people do not switch to the latest toolkit as soon as it comes out.

WinForms has been around for about ten seconds, with very, very little written in it. It does absolutely nothing for the people who have pre-existing stuff written for Windows with COM, and those who are looking at porting to Linux are looking into relevant technology to do so anyway.

I suggest you wander into an average development environment some time and see what people are developing with, and also look at customers for Java, Qt and have a chat with Mainsoft as to what their customers use and require, otherwise anything else is just technology wanking masquerading as something that people who don't know any better think will somehow magically make people port applications.

...but the majority of people do not rewrite their code overnight without a good reason, it is after all a waste of money.

That's the only bit you got right. So what about all those people with COM based applications again, that sit behind any .Net code, who will not rewrite them?

You should know better, in fact, you probably do. But it would not serve your purpose of bashing Mono yet again and would defeat your point.

Sorry Miguel, I realise it's your baby and all and you can't really admit any kind of failure now.

Ah, making things up to prove a point.

What a sad thing.

Why do I have visions of pots, kettles and black things :-)?

I suggest you try running the .Net runtime and a JRE in Wine with some applications you'd like to run some time sweetheart. That's the only way it's going to happen for the vast majority of people who have stuff written for Windows and the only option they have. As soon as that compatibility tool tells them they have COM components attached to their .Net application it's all over.

For those with existing COM server applications Wine is the only way of going outside of Windows with what they have. Porting applications from .Net to Mono simply isn't enough, because that's what the vast majority of people who've developed for Windows have their code written in. Without something like this:

http://wiki.winehq.org/Mono-Wine_bridge

and quality integration with existing development tools and IDEs on a Linux platform that makes Visual Studio users sit up and take notice, you don't have a snowball in hell's chance in getting any kind of message through to the vast majority of Windows developers who are specifically using Microsoft development tools.

I mean hell, look at that article. You've got screenshots of Visual Studio, and then Linux porting stuck on as an afterthought. What kind of advert is that for Linux development, moving to desktop Linux and the usefulness of Mono when people can't port their applications and COM components, and also open their Visual Studio projects in an equivalent and well featured IDE? Unless you can offer that to a Windows developer he or she just isn't going to be very interested, otherwise they will specifically look at cross platform tools as and when they need them.

You're promising them .Net compatibility in an attempt to get them to desktop Linux presumably, so how are they going to do development when they get there? Porting applications is about more than just taking a bunch of executables and getting them to sort-of run............with some caveats.

.Net could actually be Microsoft's great strategic blunder from a business point of view. They built an excellent API on a great platform and left the door open for everybody to clone it.
It reminds me of when IBM put together the PC and and was careless enough to leave the OS to somebody else.
Instead of patenting every other line of code, Microsoft submitted the CLI as a standard because at the time they were so worried about Java.

WinForms is the most convenient and well thought out API for GUI development, period.
And yes, it is deprecated in favour of Avalon. But looking closer at Avalon's shortcomings it will take another version number or two before it will be useable for a heavy duty app. Currently WinForms is the way to go for development on Windows.

"WinForms is the most convenient and well thought out API for GUI development, period.
And yes, it is deprecated in favour of Avalon. But looking closer at Avalon's shortcomings it will take another version number or two before it will be useable for a heavy duty app. Currently WinForms is the way to go for development on Windows."

I largely agree with your post, but I wouldn't necessarily agree that "it will take another version number or two before it [Avalon] will be useable for a heavy duty app." The new Expression Suite is WPF (Avalon). I've played with the preview version of Expression Media Encoder, and it's a pretty "heavy duty" app.

Edited 2007-06-05 15:22

You see, all .Net is is a great big object oriented wrapper around Win32 and existing COM components, and where there are things that aren't or can't be wrapped, or where performance is an issue, P/Invoke inevitably becomes an issue.

You are mistaken. .NET is NOT simply a wrapper around Win32 and COM (I believe you are thinking of VB6 and older). If you are referring to the CLR, well then - DUH! just like Java's VM has to use the native OS to facilitate it's APIs, so does .NET.

I think everyone mistakenly refers to Winforms as .NET - this is a grave mistake. Winforms was never meant to be cross-platform. Microsoft at least broke it out into is own assembly and namespace so that developers didn't HAVE to use it.

An intelligent developer (using any language) will separate the software into functional layers - one being the presentation layer. This allows modular pieces to be rewritten without having to start over. I continually see developers making this mistake. These are usually the same people who generally whine about nonsense like this.

Winforms is meant to provide a native Windows GUI interface for .NET software and no more. If some idiot developer goes and uses a Winforms combo box to sort their array of data because that's all they know how to use, then they deserve what they get. Everyone is focusing on Winforms here - what about the use of GTK# or Cocoa#? Those are clearly platform-specific (GTK happens to be "cross-platform" as well - but what about platforms that don't have an updated version of it?)

I think you miss the point of .Net. The point of .Net is not cross-platform interoperability, but rather it is yet another means of platform lock-in to Windows platform.

There is Windows Forms:
http://en.wikipedia.org/wiki/Winforms
... which is clearly designed to run on top of Windows only, and then there is Swing:
http://en.wikipedia.org/wiki/Swing_%28Java%29
... which has a primary design aim of platform independence:
http://en.wikipedia.org/wiki/Swing_%28Java%29#Architecture

If you wanted to write an application that works on more than one platform, you would not choose .Net to do it.

If you wanted to limit your market to strictly Windows platforms, and give yourself next-to-zero chance of ever making a working version on any other platform, then and only then might you consider .Net.

Man, this whole Mono thing must be a complete joke then eh? Perhaps you should email Miguel et al and let them know they are wasting their time.

It means that Mono will always be behind Windows, though, or at the least that Windows has the ability to gain advantages because Microsoft controls both. Which must mean that Linux will be second class, benefitting Microsoft Windows, just as Sun v Microsoft and the whole Microsoft Java debacle pointed out a decade ago.

I hear that argument all the time, but doesn't it work in the other direction too? Why say that Mono will always be behind Windows? You could just as easily say that Windows will always be behind Mono, because it also has some libraries and abilities that the Windows .NET implementation doesn't have.

Uhm, no?
I have successfully written a cross-platform application in C# that works on both Linux and Windows, with minimal porting effort. The application was developed on *Linux* and then ported to Windows, not vice versa. It uses GtkSharp as GUI toolkit. All in all, the development and porting of the application was much more pleasant than when I would have written the app in C++.

Swing is a joke. Its API absolutely sucks. To properly align a component I have to create hundreds of panels. Why can't they just do like GTK does? GTK's alignment features are awsome and easy to use.

Edited 2007-06-04 07:35

Of course you could also use QT.
Anyway it is good to see efforts for cross platform development going on. Even though i doubt that we will see a stream of application suddenly being ported to Linux / Unix because of mono. Heck there are hardly any "great" .NET apps out there on Windows. The adoption of .NET seems very slow, even on Windows. And in the Enterprise space most applications are written in Java.

Swing is a joke. Its API absolutely sucks. To properly align a component I have to create hundreds of panels. Why can't they just do like GTK does? GTK's alignment features are awsome and easy to use.

Having used C# 2.0 and WinForms, I can tell you it's resizable form design is much worse than Swing.

I don't doubt that that's true - Windows toolkits usually use fixed layouts. And that's why GTK is my preferred toolkit - it's cross-platform and everything is easily resizable.

"Having used C# 2.0 and WinForms, I can tell you it's resizable form design is much worse than Swing."

Either you're trolling, or haven't heard of the new TableLayoutPanel and FlowLayoutPanel controls in WinForms 2.0.

Swing is a joke. Its API absolutely sucks. To properly align a component I have to create hundreds of panels.

Only because you don't know what your doing? Ever heard of GridBagLayout.

"Only because you don't know what your doing?"
People use that same excuse every time one criticizes Swing.

"Ever heard of GridBagLayout."
Yes, and its API sucks. It's horrendously complex compared to GTK's simple HBox, VBox and Table.

Take a look at this simple dialog: http://izumi.plan99.net/kwarto/kwarto-nieuwspel.png
It took *over 400 lines of code* just to write that simple dialog! I needed *3* classes to write that - if I used less classes I would have needed even more code.
To make the spacings correct, I had to wrap components in panels. Tons of panels. And the layout is still not correct, notice how the inside the "Speler" panel has inconsistent spacing. Fixing that would require me to wrap things in *yet another* panel.
In GTK I can write that same dialog with 2 to 3 times less code.

I'm sure you're going to tell me how much my code sucks, so I invite you to download it and judge it for yourself: http://izumi.plan99.net/kwarto/kwarto.tar.bz
Look in kwarto/ui/NieuwSpelDialog.java. I challenge you to write a better-looking GUI in less code.

Edited 2007-06-04 13:30

Only because you don't know what your doing? Ever heard of GridBagLayout.

Or, to make it even easier, have a look at Matisse
http://www.netbeans.org/files/documents/4/475/matisse.html

Nobody said that it was going to provide 100% compatibility with .NET - first and foremost, its a platform for future development which will allow easier development in GNOME; second priority is compatibility with Microsofts own .NET.

With that being said, good enough compatibility which allows easier porting of applications is better than no compatibility at all. With more applications beginning to be written using .NET, both internal and large applications - the opensource community need to keep up with the play.

The opensource world don't necessarily have to have 100% compatibility; for example, look at wine and mainsoft, for example. Hopefully as more application vendors start to look at Linux as a viable target, more software will appear.

Side note; Mono 1.2.4 now officially supports Solaris x86/x64, which hopefully will mean that you can compile Banshee media player as well - which has become an awesome piece of software in such a short space of time.

Nobody said that it was going to provide 100% compatibility with .NET - first and foremost, its a platform for future development which will allow easier development in GNOME; second priority is compatibility with Microsofts own .NET.

Sorry, but the only real, sole reason why anyone outside of Gnome would find Mono remotely interesting is because of its .Net compatibility. If this wasn't the case then Mono's developers wouldn't feel the need for a Windows.Forms implementation, and wouldn't talk about the feasibility of getting Avalon working, looking at Microsoft's Silverlight and talking about Indigo.

From what we've seen so far, many people are just not keen on it being a universal way to develop for Gnome either. I also don't see any web developers doing things currently in Java, PHP, Ruby or Python getting excited about it any time soon either.

The reason is that the rest of the world has moved to managed languages. If you write an app on Windows, it will be done in C# under .net. If you write an app on OSX, it will be done in objective C. On linux? C++, or even worse, C. Sure, we have Python and Ruby and whatnot, but those are really geared towards smaller projects. Nowadays, most schools don't even teach C++ (let alone C) due to the low marketability of the language. Not only are Java/C# more efficient in terms of maintainability and developement speed, but by providing these APIs to linux, we will attract more developers then would otherwise write for the platform.


ASP.net 2.0 is completely and totally different then the technologies you listed. From what I've read, JSF will come close to offering what ASP does, but it is a new technology, and there is still a lack of an environment for JSP that offers what VS.net does for ASP.

both KDE, and ESPECIALLY gnome need a more modern language for their respective APIs. Mono is one of the few projects working to offer one.

Please tell us what platforms other than Windows Microsoft supports.


.NET is a single platform proprietary development environment.. it's only through non-sponsored rogue and legally-shaky methods its able to run anywhere except Windows.


Until I can download something from microsoft.com to run .NET apps on something other than Windows.....ITS NOT CROSSPLATFORM.

Forget your angry pills this morning?

> Until I can download something from microsoft.com to run .NET apps on something other than Windows.....ITS NOT CROSSPLATFORM.

Here you go:
http://msdn.microsoft.com/net/sscli/

I know I'm going to get flamed for this because it's not a full .NET platform with all the libraries, but the previous poster made me angry by making false claims.

>for Windows XP only


Bzzzt..


Yeah try again..here is a clue, cross platform does not mean Windows XP and Windows CE.

Damn. You're right and I'm wrong, sort of ... the thing is that the first version of SSCLI (then called ROTOR) was officially supported on FreeBSD (see
http://msdn.microsoft.com/msdnmag/issues/02/07/sharedsourcecli/). When the second version was released they tried to get it out of the door as fast as they could and to make that happen the SSCLI 2 package builds _out of the box_ on XP only. The "Platform Adaptation Layer" bits are still there though.

Oh and to nitpick a bit, the Windows CE and Windows XP are rather different platforms that use totally different code base (although the API is similar).

Edited 2007-06-05 21:50

I have followed Mono from the beginning. At the start there were in every release notes some news about Gtk# but in the last release notes you only read about Windows.Forms. Are Novell or the Mono Team planing to switch from Gtk# to Window.Forms as their "default" Toolkit?


The explanation is simple, Windows.Forms is part of the libraries that make up the core of Mono, while Gtk# is a separate package.

So when we make Mono releases, we list the major achievements in the Mono release. Gtk# has its own release schedule and is released as a separate package.

Gtk# is a binding around an existing API, while Windows.Forms is a complete stack reimplementation and there are considerable more people working on Windows.Forms than the Gtk# binding.


Also if you look at gtk.org, gtk# supports only gtk 2.6. I consider this as really bad if i see that more and more Gtk# apps enter GNOME (tomboy, beagle,...).


You are not looking in the right places, and I suspect you are not a Gtk# developer. Gtk.org seems out of date most modern distributions ship Gtk# 2.8 or 2.10.


Also i can't find a Gtk#-developer mailinglist where the development of gtk# is coordinated. I wouldn't say that Gtk# is dead but it seems like the progress becomes really slow and from the press release it seems like Mono focused more on Windows.Forms.


You did not look too hard, but its listed here (third google match, for gtksharp mailing list):

www.mono-project.com/Mailing_Lists

New features in Gtk# are documented here:

http://www.mono-project.com/GtkSharpNewInVersion2x

New ideas, and the roadmap for it is here:

http://www.mono-project.com/GtkSharpPlan

And finally, all of our desktop apps are built with GtkSharp including the upcoming MonoDevelop and the Stetic GUI designer for Gtk# (and like some other poster on the thread, we also like the fact that Gtk# apps automatically work with all kinds of font sizes, internationalized setups and l-to-r and r-to-l fonts)

But Gtk# is a mature binding nowadays, and it is being improved, while Windows.Forms 2.0 is still in its infancy (we have Winforms 1.1 done, but we are about half way to 2.0). And there are a few thousand applications that we can bring to Linux if we complete the 2.0 work, which is why we have more developers working on Windows.Forms than Gtk#.

Miguel.

I have heard other issues with Mono in terms of not releasing memory when applications quit. The GUI features are nice and everything but how does it perform compared to a GTK application written in C/C++ or Python?


If an application does not release memory when it quits, then you have a kernel bug in your hands.

You can look at performance on the Debian language shootout page, it will give you an idea of where things are.

Last time we checked Gtk+ based applications (Python vs C#) C# consumed considerably less memory, but we have not done the tests in a couple of years, so you might want to check them again

Miguel.

"I ended up using a GTK-Java library to code the UI and all my stress went away."

You should give SWT and Eclipse RCP a try. SWT wraps (using JNI, of course) native widget toolkits - Win32, Mac Cocoa, and GTK).

This gives Java GUI apps native performance and native look and feel, at least more so than Swing (generally speaking).

And what I've seen (and used) of both Swing and SWT (along with Win32, GTK, and QT), I have found SWT a bit simpler to use and learn than Swing (which is, admittedly, pretty complex).

Then there is QT-Jambi (or existing Java bindings for QT). Again, that will give native performance and look and feel.

And both SWT and QT-Jambi give full cross platform capability. It's not compile once run anywhere like Swing is, it's Package for each targeted platform. But that packaging is extremely trivial.

As for Mono/GTK# apps, I have found porting them from Linux to Windows extremely difficult (in my attempts to do so). For instance, GTK# apps like F-Spot, Banshee, etc, which run great on Linux/Gnome, can't be run on windows, even with the full GTK runtime and mono.

Then there is Microsoft. I'm not trying to spread FUD about a very good technology (which I actually consider Mono to be very good). But, even on the ECMA standardized parts of Mono (the CLR and C#), MS still owns patents. And, even though they've made a "public pledge" to not sue or try to collect royalties on those bits, there is absolutely nothing, legally speaking, stopping them from doing just that.

And is there anyone foolish enough to trust MS to "play nice"?

Then there are the non ECMA standard bits of Mono - WinForms, ASP.Net, ADO.Net. Microsoft has already publicly stated that such implementations constitutes stealing of their IP.

Finally, need I remind anyone of Microsoft's latest patent threats against Linux?

Are there intentions not completely crystal clear?

No matter how nice Mono is, and no matter how good a job Miguel and crew have done - using and/or implementing Mono is like trying to pet your friendly neighborhood coiled, rattling, rattlesnake.

Why take the risk? And yes, no matter how much anyone rationalizes it, the risk is very very real. Again, just remember Microsoft's latest patent threats against Linux.

The good news is Java, which is now being licensed under the GPL, has the JCP, has both open source and multi-vendor support and implementation, is fully cross platform, is very mature, has a huge eco-system, it's primary vendor/implentator (Sun) is extremely open source friendly, and has multiple (very good) choices for cross platform GUI development (SWT, QT-Jambi, GTK-Java, and yes, Swing).

It seems like, to me, which to choose (Java/SWT/Swing/QT or Mono/WinForms/GTK#) is a complete no-brainer.

You can choose the one with no legal risk and complete ease of porting, or you can choose the one with extreme legal risk (or at least extreme FUD risk) and greater difficulty in porting.

I know which one I choose (hint: It also makes a nice beverage!).

I know which I'll avoid (hint: it's also an infectious disease) ;-)

Edited 2007-06-04 16:03

I think the chances of Microsoft suing Free Software Developers for using Mono to write apps with non-Microsoft toolkits like GTK# are extremely remote. C# is just another language and the CLR is just another virtual machine, and there are no patents that will stand up in court for that category of software. C and Algol-like languages, object orientation, and VM's like the Smalltalk VM or the Pascal p-code system have been around for 30 years or more.

C# is not the same as Java, it is just in the same family as Java, and I think it has its own distinctive personality. From the point of view of implementing Qt bindings there are several things that C# has the Java doesn't:

- Properties which can be mapped directly onto Qt's Q_PROPERTIES

- Unsigned types

- Operator methods

- Implicit type conversions which allow you to convert from say a QBrush to a QVariant automagically

- Namespaces

- Generic types that work with reflection. QtJambi uses generic types to define signals, and this may cause problems for non-Java languages running on the JVM (or it may not, I not sure).

- Structs, which are useful for passing a stack of args to native methods

- Upper case method names as a convention. Hmm, not sure if that is a 'feature', but it certainly makes C# code look different for the equivalent Java.

We're quite close to doing a first release of the C# Qyoto Qt bindings, and people will be able to try out Qt programming with mono and decide for themselves. I personally think it works well, and complements the other choices for Qt programming like PyQt, QtRuby, QtJambi and native C++.

Edited 2007-06-04 16:25

>We're quite close to doing a first release of the C# Qyoto Qt bindings, and people will be able to try out Qt programming with mono and decide for themselves.

Sounds interesting, count me in (as soon as I learn Qt :-)

Please note this is not a flame attempt, but a genuine question.

Hey, snowflake. Can you show me an example code of non fixed layout for windows API's ? I always avoided programming on windows platforms because I couldn't stand those fixed positioning for everything.

Alexandre Moreira.

It's been about 5 years since I programmed on Windows, but from what I remember, controls in resource files were indexed by fixed co-ordinates and I don't remember ever seeing anything related to layout managers such as the grid layout. I did a google on MFC "layout manager" and only got this link which confirms that MFC didn't have one, but it is possible to roll your own: http://www.codeproject.com/dialog/layoutmgr.asp


That means, either the apps you've written 10 years ago used your own custom layout manager (in which case, I complement you on your foresight, but it doesn't help the average MFC programmer that's stuck with what Microsoft provides them), or you programmed on some non-C/C++ language like Delphi (which I think had layout managers), or you think you know what "fixed layout" means but don't, or you're BSing.

Edited 2007-06-04 16:49

Delphi doesn't have layout managers either, at least not out of the box. You can align components to left/right/top/bottom but that's nowhere near as powerful as and easy as the capabilities I'm used to in GTK. As a result, my dialogs tend to display differently for different users, depending on whether they have XP skinning turned on.
I searched for layout managers for Delphi but I haven't been able to find anything.

I think because everybody's free to invest/waste their own money/time at their will

[Flame On]
Because we like it! .NET is a very interesting, well-developed framework. The development model simplifies the creation of both Web (ASP.NET) and Desktop (WinForms) application using a very similar model. .NET makes it very easy to rapidly create applications (language RAD feature) so that I can create a complete app (main windows, controls, logic) with only a few lines of code, JUST like I can with RAD toolkits like GTK. I also like the way ASP.NET applications are created - total separation of HTML elements of a page and the code-behind logic. In the code-behind page, I can treat the cotrols on the page just like I do on a Winforms app (well, almost!).

The bottom line, the .NET framework is a very cool framework, and worthy of utilization. It isn't the big messsy world of MFC and Win32 API. I think most non-biased programmers would be pleasantly pleased with it.
[Flame Off]

I consider the merits of the .NET framwork worthy of attention. However, I do have to agree that there is the _possibility_ of Microsoft intervention at some point. But realistically, I don't see how they would have much to stand on - .NET is a much more open framework that the past Windows standards (MFC, Win32). C# is an ISO standard. I really think Microsoft may not be embracing Open Source, but they are embracing Open Standards. I look at .NET as an Open Standard, and Novell and Mr. de Icaza are implementing this standard. I really think Mono is on safe grounds.

I do agree that .Net is a very interesting framework.

I do not understand what you mean language RAD feature, is it a .Net feature or the Visual Studio.Net feature ? Mind to explain futher ?


Code-Behind concept is cool but not new. Unfortunately, most of them are "runat" server side. When dealing with javascript, the strength of code behind is not obvious.

I do agree with you that .Net is much more open than MFC, Win32. Even Mono is safe ground , however, does .Net/Mono is a better choice ?

My personal opinion, I won't refuse to code program on .Net , and I am interest to learn. However, if I would develop a large application , I really won't put .Net/Mono as first option.

I do appreciate the effort of Mono team but why we need to choose .Net/Mono when there are others choices out there ?

Because none of those choices are .NET ..