Log in

View Full Version : .NET being cross platform ?


Doom9
3rd July 2004, 22:56
MS never advertised .NET as being cross platform. Since the specs are open, a CLR could be implemented for other operating systems, which is done in two projects (mono, the one for PCs, and another one whose name I don't recall right now.. that one for PDAs). I doubt MS will ever release anything meant to run just as well on Linux as Windows.

but touting C as the best cross platform option is wrong. I've taken classes in operating system, and a lot of code that we had to write involved Unix specific system calls that you can't make on Windows. And as soon as GUIs come into play, you're dependent on the windowing system anyway which means additional APIs that are never platform independent. And the same goes for C++. I think Java is clearly THE best language when it comes to writing apps for cross platform purposes, and .NET, even though it theoretically has the potential, will never be as interoperable. I suppose it's safe to assume that if something works on the mono runtime, it will work with the MS runtime, but the other way round, I personally have my doubts too, and a year ago I actually tried running a rather simplistic socket program that I wrote in VS.NET on Linux/mono.. with no success even though at that time the socket stuff should all have been implemented in the mono runtime.. I actually wonder what would've happened had I recompiled my source code with the mono compiler.

Anyway, we've gone quite far from the original subject. It's not about what's the most compatible, what framework is the best to use, it's about whether you would install a .NET runtime for an app. We all have installed many runtimes in our lives, so if a program requires a new runtime you either install it, or look for an alternative software, and if it's worse or doesn't exist, you'll just have to live with that. Same thing goes for operating systems.. if an app only exists on Windows, you either use Windows or you just don't get to use it (well.. there are some other choices like Wine or even better vmware)

stax76
3rd July 2004, 23:26
sorry for being ot, could the topic possibly be splitted?

@Neo Neko

I simply don't understand things like how Microsoft is gonna sabotage Mono/break things without breaking their own, maybe you could justify this better to convince us. How will it be done, how did it work in the past. Why should .NET be bad for cross platform applications, if you come across a problem you can contribute to Mono and fix it what you can't do with Sun's Java. Nothing wrong with Swing or SWT, if it's all bliss then I'm sure somebody will implement something like this for .NET/Mono. Novell implements for each platform the UI with the native toolkit either WinForms, GTK# or Cocoa#. It's more work but it's justified by the fact that people will feel at home, it's not gonna be as slow then XUL or Swing and and the TreeView or ListView controls will react on the keyboard input like people are used to. The patent issue is the interesting thing about Mono, although I don't use Mono and don't plan to use Linux I'm observing the progress and development and I'm convinced the project will continue to be a great open source success story don't matter if Red Hat or Micosoft likes it or not

Neo Neko
4th July 2004, 06:43
Originally posted by Doom9
MS never advertised .NET as being cross platform. Since the specs are open, a CLR could be implemented for other operating systems, which is done in two projects (mono, the one for PCs, and another one whose name I don't recall right now.. that one for PDAs). I doubt MS will ever release anything meant to run just as well on Linux as Windows.

I am 100% sure I saw it advertised as such. But I don't have anything difinitive on hand so I'll digress for now. Needless to say the crosplatform nature "is not" being hyped as much now. But some food for thought. What is bytecode and what is the significance of .net compiling to a bytecode intermediary and interprited at a low level like Java. If your purpose is not cross platform compatability bytecode intermediary makes little sense. The wonderfull thing about bytecode is that it is fairly system neautral. Big edian little edian bytecode does not care. But if you are going to write a platform dependant language bytecode makes almost no sense what so ever. It is faster to interprited than human readable code. But at best it will only run as fast as a moderatly well writen natively compiled program. Bytecode is made for cross platform usage.

Originally posted by Doom9
but touting C as the best cross platform option is wrong. I've taken classes in operating system, and a lot of code that we had to write involved Unix specific system calls that you can't make on Windows. And as soon as GUIs come into play, you're dependent on the windowing system anyway which means additional APIs that are never platform independent.

What about the standard template libraries? Fltk? eFltk? GTK? QT? wxWidgets? Open GL? Open AL? And all the other excelent cross platform libraries I can't remember at the moment? If you want to write cross platform code it is rather easily done and has been for quite some time now. But hell as you said it is possible to create platform specific code in generally platform independant languages like Java. It depends alot on your choice of libraries. But C is very cross platform where source is concerned. Not in the same way Java is but more than .net.


Originally posted by Doom9
And the same goes for C++. I think Java is clearly THE best language when it comes to writing apps for cross platform purposes, and .NET, even though it theoretically has the potential, will never be as interoperable.

True that. But why bytecode if it is not intended to be cross platform. I can tell you why but I will leave it up to you all to come to that yourselves as I have already hinted on it.

Originally posted by Doom9
Anyway, we've gone quite far from the original subject. It's not about what's the most compatible, what framework is the best to use, it's about whether you would install a .NET runtime for an app. We all have installed many runtimes in our lives, so if a program requires a new runtime you either install it, or look for an alternative software, and if it's worse or doesn't exist, you'll just have to live with that.

Yes we have gone OT. But we are lucky to live in this time of computer renesance. Our choices are really increasing and quality is finally going up up up. Thank goodnes Microsoft has finally seen their match.

stax76
4th July 2004, 09:20
But some food for thought. What is bytecode and what is the significance of .net compiling to a bytecode intermediary and interprited at a low level like Java. If your purpose is not cross platform compatability bytecode intermediary makes little sense. The wonderfull thing about bytecode is that it is fairly system neautral. Big edian little edian bytecode does not care. But if you are going to write a platform dependant language bytecode makes almost no sense what so ever. It is faster to interprited than human readable code. But at best it will only run as fast as a moderatly well writen natively compiled program. Bytecode is made for cross platform usage.

True that. But why bytecode if it is not intended to be cross platform. I can tell you why but I will leave it up to you all to come to that yourselves as I have already hinted on it.


we are talking about distributed systems, actually there is a whole lot more why bytecode is needed, that's why I said you don't know about the technical background. I picked up a few links where you can read about key topics

http://msdn.microsoft.com/netframework/gettingstarted/default.aspx

http://msdn.microsoft.com/netframework/programming/clr/

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconcommonlanguageruntimeoverview.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconenhancingdesign-timesupport.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconhandlingthrowingexceptions.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconprogrammingessentialsforgarbagecollection.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconsecuringyourapplication.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconassembliesoverview.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconthecommontypesystem.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconautomaticmemorymanagement.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconcommonlanguagespecification.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconmetadataoverview.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconextendingmetadatausingattributes.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconnetframeworksecurity.asp

Doom9
4th July 2004, 11:58
I am 100% sure I saw it advertised as such. I think you're mixing this with language independent. That's what it's being advertised as. Write something in C++, derive from it in C#, add VB.NET, Fortran and Delphi components seamlessly (one using statement and adding a reference to your project and that's all it takes). And to achieve that, you can't have native code as those languages cannot easily interoperate. It's also one API for every language, so if you know one supported language and you know the API, you could write code in every other supported language if you're familiar with it.

What about the standard template libraries? Fltk? eFltk? GTK? QT? wxWidgets? Open GL? Open AL?I suppose STL is generally available with the OS, but the rest requires custom installation, which makes it no different from the VB runtime, MFC, ATL, Java and .NET - you still have to install custom APIs to get your program working everywhere. And most of those libraries are very *nix centric and usually force a specific platform look upon your program, which is not really a good thing imho.. there are platform design guidelines for a reason.

Wilbert
4th July 2004, 13:36
sorry for being ot, could the topic possibly be splitted?
I splitted the thread on request. I hope I did it right.

Sirber
4th July 2004, 14:23
I read somewhere that there is a perl framework compatible to .NET.

stax76
4th July 2004, 14:53
I read somewhere that there is a perl framework compatible to .NET.


Visual Studio is extendible like every serious .NET IDE, I think there is something like ActivePerl and ActivePhyton which integrates in Visual Studio. Actually there are a lot compilers for many different languages, it's even possible to compile C++ and Delphi to MSIL with little to no change and with little performance lost. Not only Microsoft managed to implement a C++ .NET compiler for the titanic C++ language, at the same time they added a lot .NET specific features to C++, if that's good or bad may be left to you, the reason is interoperability. MSIL is greatly capable to deal with different requirements like static and dynamicly typed languages. Once the code is compiled down to MSIL you have all the benefits that can be found in the links I've posted, don't matter in what language the code was written in the first place.

lexor
4th July 2004, 15:31
perhaps the point of the thread was lost when it was split, but the original Doom9's post looks a lot like an article stating things (and his experience) and not asking questions?

so could someone point out what is being discussed? I'm interested since there seem to be passionate opinions on thread without arguable points. Doom9 was quite accurate and concise in his post, and he even has a conclusion, so what's is everyone discussing?

/EDIT: umm... Wilbert where did you split the thread to? can't find anything else from here.

wmansir
4th July 2004, 15:41
It came from here: http://forum.doom9.org/showthread.php?s=&threadid=79092

The dicussion changed from installing .NET from a users perspective to developers views of .NET in general.

Perhaps this thread's title should be changed to something like: Devs discuss .NET

Then move it to the Dev forum.

Then close it when it becomes a flamewar. :) j/k

Neo Neko
7th July 2004, 00:05
Replies to more OT stuff from the split thread parent.

Originally posted by Dolemite
....instead of being factual and neutral you are spreading a lot fud. Your dislike to Microsoft totally blinds you to see actual facts. Most of your assumptions can just too easy be proved wrong.

Yet to this point you have yet to do that. Show me where I might be wrong. I would be interested to discuss that. And don't mistake general MS pessimism for blinding anti-MS sentiment. Microsoft over the yeas has in many instances and many ways shown how they are untrustworthy and only genuinly self interested. But that would be something for a PM debate. And not to the subject of this thread.

Originally posted by Dolemite
In many of your statements there is some kind of truth, it's just not right how you present them, many are totally wrong.

Yet this is only your oppinion. As opposed to mine. Is it worth it to argue oppinion only to support it with more oppinion. I know where you are coming from. I understand you. I have never said that you are wrong. Meerly that we have different views. You are coming solely from the side of Windows software development under .net which is only a small aspect of .net.

Originally posted by Dolemite
Maybe you should stop reading slashdot for some time and read at OSNews, MSDN (you know about Sun Tzu? Miguel and Bill probably do;) and Mono occasionally. You should realize then things are a little bit different.

What I realize is that you still don't understand where I am coming from. You assume you know something that I don't in the larger picture.

Originally posted by Dolemite
well, he said that he is reading slashdot, I doubt that's a good address to learn about Mono and .NET

You silly. :p When did I ever say that I was using slashdot as a resource to learn about .net and mono?

You said
Originally posted by Dolemite
Don't believe every fud people write at site like OSNews or even worse on Slashdot and rather go and test it yourself.

To which I said
Frankly I don't read OSNews. And I read slashdot for entertainment not specifically education. It tends to be more entertaining than educational.

Where does that say that everything I know of .net/mono comes from slashdot? Because that's just silly.

Originally posted by Dolemite
Neo Neko said things like bytecode is only needed because of cross platform which basically is wrong, I provided links to many benefits of MSIL and the meta data, there is even many more things. Neo Neko did not reply to this post.

Well I have already read most of that. You think that there is something there that I don't understand. But that is not the case.

Frankly bytecode will never be as fast as native code. Unless that is bytecode were native code. The sole purpose of bytecode "IS" crosplatformness and hardware obfruscation. Bytecode is a hardware neautral language. Similar to the object files generated by many compilers for decades now. The main difference between the two though is that in general .net code is never taken the next step to being native code. Exactly like java in that respect. All Microsoft has done is taken all their development languages and created a new standard hardware neautral intermediary code for them to target. Which is nothing new at all. Since many compilers have done that for decades to an extent. I have taken pascal object code that I had no source to and just an interface specification. And written a C program that used that code and linked to it at compile time to create a single self contained program.

Also if bytecode and .net bytecode specifically were every bit as fast as native code then why is MS working with INTEL and AMD to develop .net bytecode chipsets to be added to PCs to speed up .net execution time?

Originally posted by Dolemite
when it's possible to run complex technologies like COM+ (DirectX for example) under Linux, why then shouldn't run large .NET applications,

Frankly alot of that is done still using MS code and libraries. Which as a result largely ties you to the libraries and the platform they were developed for. Why is it you think that Wine is most prevalent on x86 based hardware and almost next to non existant on non x86 hardware based linux systems? Is their a transgaming wine for the Mac? I am not going to base my oppinions on the exception here. But rather the rule. Which says that unless the mono or other devs reverse engineer many of those secret or overly costly libraries/APIs [which microsoft will be waiting to sue them for] that .net code will not in general run under Mono under Linux. With x86 Linux being the one possible exception.

Originally posted by Dolemite
the .NET libs are getting better, less native calls are gonna be required.

You can say that while at the same time Microsoft is touting libraries like Avalon which are highly native to beat their competition around their head and shoulders. Curious. In any event .net gets it's slight speed advantage over Java via relying on alot of native libraries and code. To a large extent Microsoft is developing .net simply as a glue for their components. Not that .net is limited to that thankfully.

Originally posted by Dolemite
reverse engineering Win32 is probably 1000 times harder and the Wine team do a encredible job, I believe you can even run things like AviSynth in Wine.

Yes and no. You can and it is rather dificult. But really only on X86 based linux systems which is again rather an exception to the rule. It does not work under Linux or BSD in general. Not to downplay what they have done. But not to overstate it as well. They are really only beginning to address such things for non x86 systems.

Also as I said when it comes to reverse engeneering those missing parts of .net Microsoft is waiting with baited breath to sue. Microsoft can't necessarily attack them for poking around the windows API after the anti-trust trial. But .net is a whole nother hornets nest.

Originally posted by Dolemite
Managed apps shouldn't use native calls and already little to nothing are really required. If a clueless programmer hardcodes path seperators instead of using the .NET entities (yes .NET has everything for portability) than it's gonna be a crappy application anyway.

.net may not require native calls but it requires native or platform specific libraries. Which shoots down the assertion of having everything for portability.

Originally posted by Dolemite
.NET has more than enough innovation, progress and benefits, things like attributes and reflection are reasons why .NET shines, such features lead to another and much better program architecture and besides that enable you to do things that are painfully or not possible without. This concept is used in .NET all over the place and in every serious .NET program

.net is not that innovative at all. In fact basically what Microsoft has done is to take alot of pre-existing concepts that have been exposed in many different programming languages over the years and integrate them all. Microsoft never innovates. But they do integrate. .net is not truly cross platform and likely never will be even though Microsoft advertises it as such. Calling it a unified platform for providing uniform web services via many different languages. Calling it a unified platform for web services implies due to .net's rather software platform specific nature that according to Microsoft the web is Microsoft's and only Microsoft's platforms make up the web. Which is ignorant since the larger portion of the web that provides web services are not Microsoft platform servers but rather a mixture of mostly Linux with some *BSD and OSX and friends comprising a smaller part. Oddly enough Microsoft was developing .net for BSD but I am not sure if that project is still alive. But it is as close as Microsoft fealt they could get to their competitor without actually recognising them.

I do not deny the fact that .net has many nice though not neccessarily new things. That I do not deny. What I do deny is that .net comprises a unified platform for providing uniform web services. Which is Microsoft's larger intention for .net. Microsoft is banking heavily on web services as both of their cash cow departments [MS Windows and MS Office] have reached basic total market saturation and provide little or no room for revenu growth to support the company into the future. Microsoft is loosing it's previous bid for control of web services via internet explorer and it's highly lack luster reputation. All at an increasingly negative adoption rate. Microsoft is just trying a different direction to achieve the same goal of total control. They have done a great PR job so far. But if ever Microsoft has been known to innovate it has been in the area of PR. So that is to be expected. Unfortunatly it is just not their intention to deliver strictly what they are claiming or have prommised. Which is also to be expected from them.

Frankly I suspect we would agree more over all than we disagree on the subject as a whole. We are just not discussing those parts as things stand. I have in recent month's spent quite a bit of time reading up on .net and mono in general. And no; not at slashdot. And I must say there are some things I like about it. More specifically mono. Portability means alot to me. But unlike anti-Microsoft zealots or people blinded by anti-ms sentiment which in the past you have implied I am. I do not see the mono devs as opensource traitors. Actually I think .net will in the long run be a good thing but not necessarily .net itself. One of the things that has held Java back from similar achievements is the fact that Sun has seen no serious competition on that front. In escence you could say they were suffering from Microsoft syndrome. A general lack of innovation. .net and mono have caused serious re-evaluation over in the Sun Java camps. Which in my view is a great thing. If as they are currently contemplating opensource Java it could stand to be a massive boon. And speed development of projects that allow other languages to be compiled to java bytecode or java bytecode to be compiled to native code for the system of your choice. Much of which has been in the works by third parties for a long time. In the end this stands to make Java .net's equal only better. And I see that as a good thing. Call me emotionally conflicted just not blinded with anti-MS bias. :p

salute

stax76
7th July 2004, 12:18
@Neo Neko

I'm liking your last posting much more then previous one's and I would like to thank you for the effort and apologize for harsh comments. I'm having now two options, first continue to argue and second to continue developing my open source projects. I hope you can understand I decided for the second option which is after all my main interest. It's not very motivating working on .NET based open source project hearing critic comments about .NET all the time. You have to argue all the time which I'm tired of or ignoring the comments or to move to places where such comments won't appear.

Doom9
7th July 2004, 12:39
why argue? Let your software speak for you.. if it's good, people will gladly install a framework, even if they have some political opposition to it. Or they'll just learn to live with lesser alternatives.

I'm glad to have .NET available on the Windows platform.. it has made some of my work a lot easier, and I don't particularly care if people like .NET or not, if they want to use my software, they'll just have to install it.

Neo Neko
7th July 2004, 17:48
Originally posted by Dolemite
@Neo Neko

I'm liking your last posting much more then previous one's and I would like to thank you for the effort and apologize for harsh comments. I'm having now two options, first continue to argue and second to continue developing my open source projects. I hope you can understand I decided for the second option which is after all my main interest. It's not very motivating working on .NET based open source project hearing critic comments about .NET all the time. You have to argue all the time which I'm tired of or ignoring the comments or to move to places where such comments won't appear.

Good choice. Like I said; I know we agree more than we disagree. It is just irksome to see what MS is doing with .net. But it's not like it isn't the same thing they have done a thousand times before. They "are" touting it as something they hope it will never be in hopes to draw away their competitors support. [that is if you don't considder MS as controlling the web :p ] But they have unintentionally actually created another competitor this time. And all this competition can't help but be good. Java will improve. .net will be forced to improve. And it goes without saying but mono will also improve. Learning C# and mono is kind of a new pet project for me. I was learning how to use wxWidgets with C++. But it seems wxWidgets and Mono is an even better possibility. Just don't expect me to do any of that win forms stuff related to avalon. It's GTK, QT, or wxWidgets for me. :D

Doom9
7th July 2004, 18:37
something just came to mind: the prototype I wrote during the course of my thesis runs on both PCs and PDAs. Now, PDAs don't have x86 chips, in fact, Windows CE (and thus Pocket PC and MS' smartphone OS) does not work on x86 chips. Thus, .NET is actually cross-platform.. it works on different CPU architectures and different operating systems. I think that's where Neo gets cross platform from.. but that is not the same as running on x86/Win and x86/Linux.. that would be another form of cross platform, and one that MS would never advertise their products for. But since the bytecode language is standardized, the .NET strategy in a way actually backfired for MS as other companies / organizations / individuals are able to implement alternative runtimes for alternative operating systems and platforms. MS will not like the day when Mono 1.1 comes out, as it promises Windows forms even for Linux. By Mono 1.1 the whole MS .NET 1.1 featureset should be supported.. it's going to be interesting to see if apps will be portable by then.

But, my PDA-centric prototype can be run on a PC already today.

wmansir
7th July 2004, 23:56
JonLech just posted about his latest release here (http://forum.doom9.org/showthread.php?s=&postid=521226#post521226), noting it was cross-platform with a link (and a wink) to this thread. It reminded me of the state of confusion on Slashdot when he first released DeDRM with C# source code. It was kind of like going to Woodstock with a peace sign drawn in blood.

Neo Neko
8th July 2004, 02:22
Originally posted by Doom9
something just came to mind: the prototype I wrote during the course of my thesis runs on both PCs and PDAs. Now, PDAs don't have x86 chips, in fact, Windows CE (and thus Pocket PC and MS' smartphone OS) does not work on x86 chips. Thus, .NET is actually cross-platform.. it works on different CPU architectures and different operating systems. I think that's where Neo gets cross platform from..

Smack on. Bytecode makes it hardware portable/neautral. But that only goes so far as the "hardware platform".

Originally posted by Doom9
but that is not the same as running on x86/Win and x86/Linux.. that would be another form of cross platform,

Yes software platform. A platform can be either hardware or software. Or it can involve both. .net itself "is" portable/cross platform as far as hardware is concerned. Just like Java. Microsoft just did not go the next step of making it portable acrost software platforms like Sun did with Java. But then again no one other than Microsoft has accused Microsoft of being a benevolent company. In this way they can folow their principal of embrace and extend while still locking in customers.

Originally posted by Doom9
and one that MS would never advertise their products for. But since the bytecode language is standardized, the .NET strategy in a way actually backfired for MS as other companies / organizations / individuals are able to implement alternative runtimes for alternative operating systems and platforms.

Actually it is kind of on the fence at the moment. Microsoft got a head start. And they are still ahead. But even with Mono, DotGNU, and Portable dotNet coming out control has not yet tipped out of the hands of Microsoft. But we know Microsoft can't compete with anyone on fair ground. So if all the competitors get their ducks in a row and work together it is concievable that some day in the not so distant future that people may discuss Mono and mention in passing the less used Mono compatable .net framework on MS Windows. :p

Originally posted by Doom9
MS will not like the day when Mono 1.1 comes out, as it promises Windows forms even for Linux. By Mono 1.1 the whole MS .NET 1.1 featureset should be supported.. it's going to be interesting to see if apps will be portable by then.

Well before it can be tested by us for compatability it will have to be released first. And if the Mono devs are actually going to deliver on those promises then Novell and the devs are going to have to prepare to go to court. Since as I understand things Microsoft is rumored to be very protective of the 30% of .net they did not submit for open standardisation. And it is not going to be an easy process. If novell etc are prepared to fight and not roll over then this will involve dispatching multiple invalid pattents and a general large expendature of capital and resources. And even if Novell wins against SCOX it will take some time before they are back to full strength. And they are going to need that strength to face the malicious monopoly. :p

Originally posted by Doom9
But, my PDA-centric prototype can be run on a PC already today.

As long as it is an MS operating system. ;) Keep us up to date on your OSX or non x86 Linux progress though. :D Actually even if Mono never gets wrapper support for winforms there is an alternative. Though it would not be interoperable with winforms. wx.Net could possibly ultimatly replace winforms even under MS Windows. It provides a uniform interface to render in native widget sets under almost any OS. :D